* Ulf Hansson <[email protected]> [181004 15:02]: > On 4 October 2018 at 15:48, Tony Lindgren <[email protected]> wrote: > > Hi, > > > > * Ulf Hansson <[email protected]> [181003 14:43]: > >> + * GENPD_FLAG_IRQ_SAFE: This informs genpd that its backend > >> callbacks, > >> + * ->power_on|off(), doesn't sleep. Hence, these > >> + * can be invoked from within atomic context, > >> which > >> + * enables genpd to power on/off the PM domain, > >> + * even when pm_runtime_is_irq_safe() returns > >> true, > >> + * for any of its attached devices. Note that, a > >> + * genpd having this flag set, requires its > >> + * masterdomains to also have it set. > >> + * > > > > Let's try to avoid adding more irq_safe stuff because of having that > > propagate to the masterdomains.. > > I am not sure I get your point. This is just documenting existing > functionality in genpd, there is nothing new here.
Right, and I'm just bringing up that this FLAG_IRQ_SAFE is not a good way to in the long run :) > > I think you can just flag the power_on/off in genpd, then have cpu_pm > > callbacks do it. > > Not really sure what you propose, but feel free to send a patch. Well there is not much to really patch, just don't attempt to do irq_safe stuff from genpd and have cpu_idle callbacks to do it instead. And then no need for GENPD_FLAG_IRQ_SAFE :) > Do note, genpd has since the beginning of its time tried to cope with > pm_runtime_irq_safe() devices. I admit it's quite complicated, however > GENPD_FLAG_IRQ_SAFE greatly improved the support for such devices and > their PM domains. Moreover, we need this functionality, in one way or > the other, as long as there users of pm_runtime_irq_safe(). Right, and I'm still struggling years after with legacy device drivers that have done pm_runtime_irq_safe() and come to the conclusion that it should not be used at all. Getting rid of GENPD_FLAG_IRQ_SAFE might just safe you years of pain later on. Regards, Tony
