On 18 January 2016 at 17:58, Lina Iyer <lina.iyer@xxxxxxxxxx> 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 -- 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
