linux-stable.git/drivers/gpu/drm/stm, branch linux-5.10.y

drm/stm: Fix an error handling path in stm_drm_platform_probe()

2024-10-17T13:07:46+00:00

[ Upstream commit ce7c90bfda2656418c69ba0dd8f8a7536b8928d4 ]

If drm_dev_register() fails, a call to drv_load() must be undone, as
already done in the remove function.

Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Christophe JAILLET 
Acked-by: Raphael Gallais-Pou 
Link: https://patchwork.freedesktop.org/patch/msgid/20fff7f853f20a48a96db8ff186124470ec4d976.1704560028.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Raphael Gallais-Pou 
Signed-off-by: Sasha Levin

stm: ltdc: fix two incorrect NULL checks on list iterator

2022-06-09T08:21:27+00:00

commit 2e6c86be0e57079d1fb6c7c7e5423db096d0548a upstream.

The two bugs are here:
	if (encoder) {
	if (bridge && bridge->timings)

The list iterator value 'encoder/bridge' will *always* be set and
non-NULL by drm_for_each_encoder()/list_for_each_entry(), so it is
incorrect to assume that the iterator value will be NULL if the
list is empty or no element is found.

To fix the bug, use a new variable '*_iter' as the list iterator,
while use the old variable 'encoder/bridge' as a dedicated pointer
to point to the found element.

Cc: stable@vger.kernel.org
Fixes: 99e360442f223 ("drm/stm: Fix bus_flags handling")
Signed-off-by: Xiaomeng Tong 
Acked-by: Raphael Gallais-Pou 
Signed-off-by: Philippe Cornu 
Link: https://patchwork.freedesktop.org/patch/msgid/20220327055355.3808-1-xiam0nd.tong@gmail.com
Signed-off-by: Greg Kroah-Hartman

drm/stm: Fix bus_flags handling

2021-05-14T07:50:22+00:00

[ Upstream commit 99e360442f223dd40fc23ae07c7a263836fd27e6 ]

The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no
matter what polarity the next bridge or display might require, these flags
are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set
and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and
DISPLAY_FLAGS_DE_HIGH were always set.

The fix for this problem is taken almost verbatim from MXSFB driver. In
case there is a bridge attached to the LTDC, the bridge might have extra
polarity requirements, so extract bus_flags from the bridge and use them
for LTDC configuration. Otherwise, extract bus_flags from the connector,
which is the display.

Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Marek Vasut 
Signed-off-by: Yannick Fertre 
Cc: Alexandre Torgue 
Cc: Antonio Borneo 
Cc: Benjamin Gaignard 
Cc: Maxime Coquelin 
Cc: Philippe Cornu 
Cc: Sam Ravnborg 
Cc: Vincent Abriou 
Cc: Yannick Fertre 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
Tested-by: Yannick Fertre 
Signed-off-by: Philippe Cornu 
Link: https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-marex@denx.de
Signed-off-by: Sasha Levin

drm/stm: repair runtime power management

2020-07-08T09:47:01+00:00

Add missing pm_runtime_get_sync() into ltdc_crtc_atomic_enable() to
match pm_runtime_put_sync() in ltdc_crtc_atomic_disable(), otherwise
the LTDC might suspend via runtime PM, disable clock, and then fail
to resume later on.

The test which triggers it is roughly -- run qt5 application which
uses eglfs platform and etnaviv, stop the application, sleep for 15
minutes, run the application again. This leads to a timeout waiting
for vsync, because the LTDC has suspended, but did not resume.

Fixes: 35ab6cfbf211 ("drm/stm: support runtime power management")
Signed-off-by: Marek Vasut 
Cc: Yannick Fertré 
Cc: Philippe Cornu 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
To: dri-devel@lists.freedesktop.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Philippe Cornu 
Tested-by: Yannick Fertre 
Signed-off-by: Benjamin Gaignard 
Link: https://patchwork.freedesktop.org/patch/msgid/20200229221649.90813-1-marex@denx.de

drm/stm: ltdc: remove call of pm-runtime functions

2020-07-08T09:46:26+00:00

It is not necessary to suspend or stop the ltdc clocks
to modify the pixel clock.

Signed-off-by: Yannick Fertre 
Acked-by: Philippe Cornu 
Signed-off-by: Benjamin Gaignard 
Link: https://patchwork.freedesktop.org/patch/msgid/20200701120402.6444-1-yannick.fertre@st.com

drm/stm: Set GEM CMA functions with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE

2020-06-10T07:05:32+00:00

DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE sets the functions in
struct drm_driver to their defaults. No functional changes are
made.

v2:
	* update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Philippe Cornu 
Reviewed-by: Emil Velikov 
Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-35-tzimmermann@suse.de

drm/stm: Use GEM CMA object functions

2020-06-10T07:05:25+00:00

Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
allocates the object and sets CMA's default object functions. Corresponding
callbacks in struct drm_driver are cleared. No functional changes are made.

Driver and object-function instances use the same callback functions, with
the exception of vunmap. The implementation of vunmap is empty and left out
in CMA's default object functions.

v3:
	* convert to DRIVER_OPS macro in a separate patch

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Philippe Cornu 
Reviewed-by: Emil Velikov 
Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-34-tzimmermann@suse.de

drm/stm: ltdc: check number of endpoints

2020-04-27T13:42:12+00:00

Number of endpoints could exceed the fix value MAX_ENDPOINTS(2).
Instead of increase simply this value, the number of endpoint
could be read from device tree. Load sequence has been a little
rework to take care of several panel or bridge which can be
connected/disconnected or enable/disable.

Signed-off-by: Yannick Fertre 
Signed-off-by: Benjamin Gaignard 
Link: https://patchwork.freedesktop.org/patch/msgid/1582877258-1112-1-git-send-email-yannick.fertre@st.com

drm/stm: Drop explicit drm_mode_config_cleanup call

2020-03-26T15:06:00+00:00

It's right above the drm_dev_put().

This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().

Aside: Another driver with a bit much devm_kzalloc, which should
probably use drmm_kzalloc instead ...

v2: Explain why this cleanup is possible (Laurent).

v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)

Cc: Sam Ravnborg 
Cc: Thomas Zimmermann 
Acked-by: Sam Ravnborg 
Acked-by: Philippe Cornu 
Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
Cc: Yannick Fertre 
Cc: Philippe Cornu 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-39-daniel.vetter@ffwll.ch

drm/bridge: Extend bridge API to disable connector creation

2020-02-26T11:31:23+00:00

Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:

- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple components. For instance a
pipeline with a bridge connected to the DDC signals to read EDID data,
and another one connected to the HPD signal to detect connection and
disconnection, will not be possible to support through this model.

- It requires every bridge driver to implement similar connector
handling code, resulting in code duplication.

- It assumes that a bridge will either be wired to a connector or to
another bridge, but doesn't support bridges that can be used in both
positions very well (although there is some ad-hoc support for this in
the analogix_dp bridge driver).

In order to solve these issues, ownership of the connector should be
moved to the display controller driver (where it can be implemented
using helpers provided by the core).

Extend the bridge API to allow disabling connector creation in bridge
drivers as a first step towards the new model. The new flags argument to
the bridge .attach() operation allows instructing the bridge driver to
skip creating a connector. Unconditionally set the new flags argument to
0 for now to keep the existing behaviour, and modify all existing bridge
drivers to return an error when connector creation is not requested as
they don't support this feature yet.

The change is based on the following semantic patch, with manual review
and edits.

@ rule1 @
identifier funcs;
identifier fn;
@@
 struct drm_bridge_funcs funcs = {
 	...,
 	.attach = fn
 };

@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
statement S, S1;
@@
 int fn(
 	struct drm_bridge *bridge
+	, enum drm_bridge_attach_flags flags
 )
 {
 	... when != S
+	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+		DRM_ERROR("Fix bridge driver to make connector optional!");
+		return -EINVAL;
+	}
+
 	S1
 	...
 }

@ depends on rule1 @
identifier rule1.fn;
identifier bridge, flags;
expression E1, E2, E3;
@@
 int fn(
 	struct drm_bridge *bridge,
 	enum drm_bridge_attach_flags flags
 ) {
 <...
 drm_bridge_attach(E1, E2, E3
+	, flags
 )
 ...>
 }

@@
expression E1, E2, E3;
@@
 drm_bridge_attach(E1, E2, E3
+	, 0
 )

Signed-off-by: Laurent Pinchart 
Reviewed-by: Boris Brezillon 
Acked-by: Sam Ravnborg 
Reviewed-by: Tomi Valkeinen 
Tested-by: Sebastian Reichel 
Reviewed-by: Sebastian Reichel 
Acked-by: Daniel Vetter 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com