Hello,
This series fixes crashes in the omapdss driver at both load and unload
time, due to runtime PM problems related to probe deferral. The bugs got
introduced in v4.20-rc, this should thus be considered as v4.20 fixes.
At the core of the problem comes commit 27d624527d99 ("drm/omap: dss:
Acquire next dssdev at probe time") which can cause probe deferral for
the DSS when the encoder and panel modules are not loaded yet. As the
omapdss module contains drivers for the DSS and all its children, this
results in the internal encoders being probed before the DSS. Missing
runtime PM handling around register access then caused imprecise
external aborts.
Patch 1/3 moves population of the DSS children from arch code to the
omapdss driver. This prevents the DSS children from being probed before
the DSS. The change can be considered as a workaround in the sense that
runtime PM of the DSS children should operate correctly even when the
DSS probe fail. However, given that reducing the amount of arch code is
an improvement in itself, I believe the solution to be acceptable.
Patches 2/3 and 3/3 then ensure that the HDMI4 and DSI devices are
active at bind and probe time respectively, in order to access hardware
registers there.
Tony, patch 1/3 touches both the mach-omap2 and omapdss. Would you be
fine merging it through the DRM tree ? I don't think there's a risk of
conflict during the v4.20-rc cycle.
Laurent Pinchart (3):
drm/omap: Populate DSS children in omapdss driver
drm/omap: hdmi4: Ensure the device is active during bind
drm/omap: dsi: Ensure the device is active during probe
arch/arm/mach-omap2/display.c | 111 +++++++++++++---------------
drivers/gpu/drm/omapdrm/dss/dsi.c | 25 +++++--
drivers/gpu/drm/omapdrm/dss/dss.c | 11 ++-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++-
4 files changed, 91 insertions(+), 66 deletions(-)
--
Regards,
Laurent Pinchart
