[v2,0/4] omapdrm: Fix runtime PM issues at module load and unload time

Message

Laurent Pinchart Nov. 5, 2018, 3:10 p.m. UTC

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/4 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/4 and 3/4 then ensure that the HDMI4 and DSI devices are
active at bind and probe time respectively, in order to access hardware
registers there.

Patch 4/4 finally works around an issue in the runtime PM handlers of
the internal encoders that try to manage the DISPC runtime PM state when
the DISPC may not be available. This is a bit of a hack and should be
fixed by moving DISPC runtime PM handling out of the internal encoders
runtime PM handlers, but that will require more testing and should not
be rushed during the -rc period.

Tony, this series should fix the issues you've reported. I have tested
it on both Pandaboard and AM57xx EVM, loading and unloading modules and
exercising the display with kmstest.

Patch 1/4 touches both the mach-omap2 and omapdss. Would it be OK
merging it through the DRM tree ? I don't think there's a risk of
conflict during the v4.20-rc cycle.

Laurent Pinchart (4):
  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
  drm/omap: Work around missing DISPC in runtime PM handlers

 arch/arm/mach-omap2/display.c       | 111 +++++++++++++---------------
 drivers/gpu/drm/omapdrm/dss/dsi.c   |  29 ++++++--
 drivers/gpu/drm/omapdrm/dss/dss.c   |  11 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c |  29 ++++++--
 drivers/gpu/drm/omapdrm/dss/hdmi5.c |  19 ++++-
 drivers/gpu/drm/omapdrm/dss/venc.c  |  19 ++++-
 6 files changed, 140 insertions(+), 78 deletions(-)