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

[Ulf Hansson]

On 18 January 2016 at 17:58, Lina Iyer <lina.iyer at linaro.org> 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.
>
> That said, I probably won't encounter this limitation in my current
> series, but its not hard to foresee this corner case.

Okay, thanks for sharing your thoughts.

For now, I suggest we leave case 1) as a non-supported option.

When we have a valid use case for case 1), we anyway will have to
think of a better approach than what's suggested in $subject patch,
since keeping the parent domain always powered on isn't good enough.

Kind regards
Uffe