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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |