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