Re: [PATCH RFC 08/27] PM / Domains: Support IRQ safe PM domains

[Lina Iyer <lina.iyer@linaro.org>]

On Mon, Jan 18 2016 at 09:58 -0700, Lina Iyer wrote:
>On Fri, Jan 15 2016 at 15:08 -0700, Ulf Hansson wrote:
>>[...]
>>
>>>>I think case 2 and case 3 should be okay to support, but I am really
>>>>questioning case 1.
>>>>
>>>With you other patch, it does make sense to have 2 and 3 instead of 1
>>>and 2.
>>
>>Okay!
>>
>>>My only concern is as I view the SoC as a whole, there would be cases
>>>where the parent domain could only be non-IRQ safe (turning off a big
>>>regulator may require some sleep) and the subdomains are quicker and
>>>faster IRQ-safe domains. Putting up this restriction, chops up the
>>
>>Just because they are "quick" (don't sleep) doesn't mean they have to
>>set the IRQ safe flag for the domain.
>>
>>Let's compare how pm_runtime_irq_safe() is used for devices in
>>drivers. Lots of corresponding runtime PM callbacks don't sleep, but
>>that don't mean that the driver calls pm_runtime_irq_safe().
>>
>>Drivers that are expecting to invoke pm_runtime_get_sync() (or other
>>synchronous runtime PM API) from atomic context, requires the
>>corresponding runtime PM callbacks to be IRQ safe. Only under these
>>circumstances the pm_runtime_irq_safe() is used.
>>
>I agree.
>
>The limitation and the interpretation could completely be s/w. There is
>nothing preventing that in hardware. So we could have a processor
>subsystem domain that can collapse faster and even during cpuidle. We
>would define that domain IRQ-safe because of its need to collapse and
>resume when IRQs are disabled, but its parent may not have that
>restriction, in fact, the parent could have another child that could
>only operate as non-IRQ safe.
>
>By imposing the limitation that parents of IRQ-safe domains cannot be 
>non-IRQ-safe, we have to chop off that relationship, because of 
>another
>non-IRQ-safe sibling.
>
>>>domain hierarchy. Imagine, if you could represent the whole power domain
>>>organization in DT, but because of this restriction, we may not be able
>>>to do that.
>>
>>You do have a point. Considering my comment above, do you still think
>>this may become an issue?
>>
>Yes. Pls see my example below.
>
Sorry above ;)

>That said, I probably won't encounter this limitation in my current
>series, but its not hard to foresee this corner case.
>
>Thanks,
>Lina