[...] >> 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. > 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? 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
