14.11.2019 23:31, Thierry Reding пишет: > On Sun, Aug 11, 2019 at 09:39:32PM +0300, Dmitry Osipenko wrote: >> The drivers core bumps runtime PM refcount during of entering into >> suspend to workaround some problem where parent device may become turned >> off before its children. In order to disable and reset CRTCs/HDMI/etc >> hardware, the runtime PM needs to be "forced" into suspend mode. >> >> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx> >> --- >> >> Changelog: >> >> v2: The SYSTEM_SLEEP_PM_OPS are now set for all of the relevant drivers and >> not only for the DC because turned out that they all should enforce the >> suspending. >> >> drivers/gpu/drm/tegra/dc.c | 2 ++ >> drivers/gpu/drm/tegra/dpaux.c | 2 ++ >> drivers/gpu/drm/tegra/dsi.c | 2 ++ >> drivers/gpu/drm/tegra/hdmi.c | 2 ++ >> drivers/gpu/drm/tegra/hub.c | 2 ++ >> drivers/gpu/drm/tegra/sor.c | 2 ++ >> drivers/gpu/drm/tegra/vic.c | 2 ++ >> 7 files changed, 14 insertions(+) > > I'm not exactly sure I understand why this is necessary. Runtime PM is > controlled by the drivers themselves so that when an output (say SOR) is > disabled, it drops the runtime PM reference. The idea is that since the > disabled output is no longer needed it can just go into a low power mode > which on Tegra usually means clocks off and reset asserted (and in some > cases also power domain off). > > DRM/KMS has system-level suspend support, which we use to disable all > outputs when entering suspend. I see that, unfortunately, this doesn't > seem to actually cause the devices to runtime suspend. I'm pretty sure > that this used to work at some point, so I don't know what changed. I'd > have to look into this a little more. The core doing something like this > behind the driver's back seems wrong and having to force the device into > suspend mode seems like it's just piling up on the workarounds. Please let me know if you'll find a better solution.
