linux/drivers/video/fbdev/omap2, branch v4.2

OMAPDSS: Fix omap_dss_find_output_by_port_node() port refcount decrement

2015-08-10T09:22:40Z

Fix omap_dss_find_output_by_port_node() port parameter refcount decrementation. The only user of dss_of_port_get_parent_device() function is omap_dss_find_output_by_port_node() and it assumes the refcount of the port parameter is not decremented by the call. Signed-off-by: Jyri Sarha Signed-off-by: Tomi Valkeinen

OMAPDSS: Fix node refcount leak in omapdss_of_get_next_port()

2015-08-10T09:22:35Z

Fix node refcount leak in omapdss_of_get_next_port(). Signed-off-by: Jyri Sarha Signed-off-by: Tomi Valkeinen

OMAPDSS: fix probing if rfbi device is enabled

2015-07-02T12:20:10Z

After the commit 736e60ddc215b85e73bbf7da26e1cde84cc9500f ("OMAPDSS: componentize omapdss") the dss core device will wait until all the subdevices have been successfully probed. However, we don't have a working driver for RFBI, so if RFBI device exists, omapdss will never get probed. All the .dtsi files set RFBI as disabled, except am4372.dtsi. This causes omapdss probe to not finish on AM4 devices. This patch makes omapdss driver skip adding rfbi device as a subcomponent, solving the issue. This should be reverted when we have a working RFBI driver. Signed-off-by: Tomi Valkeinen Reported-by: Felipe Balbi

Merge omapdss scaling fixes

2015-06-22T11:56:01Z

OMAPDSS: HDMI: wait for framedone when stopping video

2015-06-17T12:53:40Z

At the moment when HDMI video output is stopped, we just clear the enable bit and return. While it's unclear if this can cause any issues, I think it's still better to wait for FRAMEDONE interrupt after clearing the enable bit so that we're sure the HDMI IP has finished. As we don't have any ready-made irq handling for HDMI, and this only needs to be done when disabling the HDMI output, this patch implements a simple loop with sleep, polling the FRAMEDONE bit. Signed-off-by: Tomi Valkeinen

OMAPDSS: HDMI4: fix error handling

2015-06-17T12:44:29Z

Error handling in hdmi_power_on_full() is not correct, and could leave resources unfreed. Fix this by arranging the error labels correctly. Signed-off-by: Tomi Valkeinen

OMAPDSS: DISPC: scaler debug print

2015-06-17T12:44:29Z

Improve the DISPC debug print for scaling. Signed-off-by: Tomi Valkeinen

OMAPDSS: DISPC: do only y decimation on OMAP3

2015-06-17T12:44:29Z

The current driver does both x and y decimation on OMAP3 DSS. Testing shows that x decimation rarely works, leading to underflows. The exact reason for this is unclear, as the underflows seem to happen even with low pixel clock rates, and I would presume that if the DSS can manage a display with 140MHz pixel clock, it could manage x decimation with factor 2 with a low pixel clock (~30MHz). So it is possible that there is a problem somewhere else, in memory management, or DSS DMA, or similar. I have not found anything that would help this. So, to fix the downscaling scaling, this patch removes x decimation for OMAP3. This will limit some of the more demanding downscaling scenarios, but one could argue that using DSS to downscale such a large amount is insane in the first place, as the produced image is rather bad quality. Signed-off-by: Tomi Valkeinen

OMAPDSS: DISPC: check if scaling setup failed

2015-06-17T12:44:28Z

The DISPC's scaling code seems to presume that decimation always succeeds, and so we always do find a suitable downscaling setup. However, this is not the case, and the algorithm can fail. When that happens, the code just proceeds with wrong results, causing issues later. Add the necessary checks to bail out if the scaling algorithm failed. Signed-off-by: Tomi Valkeinen

OMAPDSS: DISPC: fix 64 bit issue in 5-tap

2015-06-17T12:44:28Z

The DISPC driver uses 64 bit arithmetic to calculate the required clock rate for scaling. The code does not seem to work correctly, and instead calculates with 32 bit numbers, giving wrong result. Fix the code by typecasting values to u64 first, so that the calculations do happen in 64 bits. Signed-off-by: Tomi Valkeinen