Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support

[Rafael J. Wysocki]

On Wed, Nov 9, 2016 at 4:07 PM, Marek Szyprowski
<m.szyprowski@xxxxxxxxxxx> wrote:
> Hi Luis,
>
>
> On 2016-11-08 23:14, Luis R. Rodriguez wrote:
>>
>> On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote:
>>>
>>> Hi Luis
>>>
>>>
>>> On 2016-10-06 19:37, Luis R. Rodriguez wrote:
>>>>
>>>> On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote:
>>>>>
>>>>> This patch uses recently introduced device links to track the runtime
>>>>> pm
>>>>> state of the master's device. This way each SYSMMU controller is
>>>>> runtime
>>>>> activated when its master's device is active
>>>>
>>>> instead of?
>>>
>>> instead of keeping SYSMMU controller runtime active all the time.
>>
>> I thought Rafael's work was for suspend/resume, not for runtime suspend.
>> Is it for both ?
>
>
> Yes, it solves both problems, although the suspend/resume was easy to
> workaround just by using LATE_SLEEP_OPS.

Right, but that's just in this particular case, because the dependency
chain is of length 2. :-)

If you had a longer chain, you might in theory use  the _noirq() stage
somehow, but that has limitations.

>> Because as far as I can tell this was painted to help
>> with suspend/resume ?

It helps with three things, (async) suspend/resume, runtime PM and
shutdown (that last part is the hardest to figure out).  The ordering
in which all of these are carried out is analogous and cannot be
determined correctly by the device registration ordering itself in
general (which has been a known fact for years, but some localized
workarounds were put in some places to work around that).

Moreover, even if the list ordering (of dpm_list, for instance) is
correct, it still doesn't guarantee the right ordering of actions that
are carried out asynchronously.  They are all started in the list
order, but they may be running in parallel with each other and
complete at different times.  For this reason, there needs to be a way
to ensure that, say, the suspend operations for consumer devices
complete before their suppliers will become unavailable and so on.

Both runtime PM and system suspend/resume have this problem.  It is
not present in the system shutdown case, but it still helps to get a
correct list ordering (ie. such that won't cause supplier devices to
be shut down before their consumers) in this case too.

Thanks,
Rafael