linux-stable.git/drivers/video/fbdev/omap2/dss, branch linux-4.4.y

drm/omap: fix possible object reference leak

2020-10-01T09:11:53+00:00

[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]

The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.

Signed-off-by: Wen Yang 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Mukesh Ojha 
Cc: Tomi Valkeinen 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sebastian Reichel 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: Markus Elfring 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Sasha Levin

omapfb: dss: Fix max fclk divider for omap36xx

2020-08-26T08:27:10+00:00

There appears to be a timing issue where using a divider of 32 breaks
the DSS for OMAP36xx despite the TRM stating 32 is a valid
number.  Through experimentation, it appears that 31 works.

This same fix was issued for kernels 4.5+.  However, between
kernels 4.4 and 4.5, the directory structure was changed when the
dss directory was moved inside the omapfb directory. That broke the
patch on kernels older than 4.5, because it didn't permit the patch
to apply cleanly for 4.4 and older.

A similar patch was applied to the 3.16 kernel already, but not to 4.4.
Commit 4b911101a5cd ("drm/omap: fix max fclk divider for omap36xx") is
on the 3.16 stable branch with notes from Ben about the path change.

Since this was applied for 3.16 already, this patch is for kernels
3.17 through 4.4 only.

Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Cc:  #3.17 - 4.4
CC: 
Signed-off-by: Adam Ford 
Signed-off-by: Greg Kroah-Hartman

OMAPDSS: fix timings for VENC to match what omapdrm expects

2015-12-09T10:57:13+00:00

Otherwise check_timings fails and we get a "has no modes" message
from xrandr.

This fix makes the venc assume PAL and NTSC timings that match the
timings synthetized by copy_timings_drm_to_omap() from omapdrm
mode settings so that check_timings() succeeds.

Tested on: BeagleBoard XM, GTA04 and OpenPandora

Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Tomi Valkeinen

OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

2015-09-24T10:46:09+00:00

Reconfigure and restart audio when display is enabled, if audio
playback was active before. This is needed in a situation when an
audio+video stream application opens the audio stream before the
video. When video stream is opened the display mode may change and
that aborts audio playback, because the display is momentarily
turned off.

The audio configuration is stored when it is successfully applied and
a boolean is set when the audio playback is started and unset when
stopped. This data is used to reconfigure the audio when display is
re-enabled. The audio playback is aborted if the reconfiguration fails.

A new spin lock is introduced in order to protect state variables
related to audio playback status. This is needed for the transition
from display enabled state (when audio start/stop commands can be
written to HW) to display disabled state (when audio start/stop
commands update only the hdmi.audio_playing variable) to always
serialize correctly with the start/stop audio commands. The already
existing mutex can not be used, because the audio start and stop
commands are executed in atomic context.

For example: when display is turned back on we take the spinlock and
we can be sure that the audio start/stop status will not change while
we update the HW according to hdmi.audio_playing state and set
hdmi.display_enabled to true. After releasing the lock
hdmi.display_enabled is true and all audio_start and audio_stop
commands write their stuff directly to HW.

Signed-off-by: Jyri Sarha 
Signed-off-by: Tomi Valkeinen

OMAPDSS: Fix omap_dss_find_output_by_port_node() port refcount decrement

2015-08-10T09:22:40+00:00

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:35+00:00

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:10+00:00

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:01+00:00

OMAPDSS: HDMI: wait for framedone when stopping video

2015-06-17T12:53:40+00:00

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:29+00:00

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