Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm

From: Luis R. Rodriguez
Date: Wed Nov 09 2016 - 18:55:36 EST


On Tue, Nov 08, 2016 at 04:30:44PM +0100, Lukas Wunner wrote:
> On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
> > On 2016-11-07 22:47, Luis R. Rodriguez wrote:
> > > Has there been any review of the existing similar solutions out there
> > > such as the DRM / audio component framework? Would that help ?
> >
> > Nope, none of that solution deals with runtime pm.
>
> Well, they do. Hybrid graphics laptops often have an HDA controller
> on the discrete GPU and I assume that's what Luis meant. There's code
> in drivers/gpu/vga/vga_switcheroo.c to make this (only sort of) work:
>
> * When the GPU is powered up/down, the HDA controller's driver is
> instructed to pm_runtime_get/put the HDA device (see call to
> set_audio_state() in vga_switcheroo_set_dynamic_switch()).
>
> * When a runtime PM ref is acquired on the HDA device, the
> GPU is powered up (see vga_switcheroo_runtime_resume_hdmi_audio()).
>
>
> Unfortunately this is all fairly broken, e.g.:
>
> * If a runtime PM ref on the HDA device is held for more than 5 sec
> (autosuspend delay of the GPU), the GPU will be powered down and
> the HDA device will become inaccessible, regardless of the runtime
> PM ref still being held (because vga_switcheroo_set_dynamic_switch()
> doesn't check the refcount of the HDA device).
>
> * The DRM device is afforded direct-complete but the HDA device is not.
> If the GPU is handled earlier by dpm_suspend(), then runtime PM will
> have been disabled on the GPU and thus the HDA device will fail to
> runtime resume before system sleep.
>
> Rafael's series allows representation of such inter-device dependencies
> in the PM core and can thus replace kludgy and broken "solutions" like
> the one above.
>
> There's one thing that I haven't understood myself though: In an e-mail
> exchange in September Rafael has argued that the above-mentioned hybrid
> graphics use case "isn't a good [example] IMO. That clearly is a case
> when two (or more) devices share power resources controlled by a single
> on/off switch. Which is a clear use case for a PM domain."
>
> The same seems to apply to Marek's SYSMMU use case. When applying device
> links to SYSMMU or hybrid graphics, we select one of the devices in the
> PM domain as master and have the other one depend on it as slave, i.e.
> a synthetic hierarchical relationship is established.
>
> I've responded to Rafael on September 18 that this can't be solved with
> a struct dev_pm_domain, but haven't received a reply since:
> https://lkml.org/lkml/2016/9/18/103

Rafael note:

The one he asked here.

Luis