Messages in this thread | | | Date | Thu, 17 Feb 2022 13:02:04 +0300 | Subject | Re: [PATCH v2] PM: domains: Prevent power off for parent unless child is in deepest state | From | Dmitry Osipenko <> |
| |
16.02.2022 12:45, Ulf Hansson пишет: > On Tue, 15 Feb 2022 at 22:49, Dmitry Osipenko <digetx@gmail.com> wrote: >> >> 04.02.2022 13:16, Ulf Hansson пишет: >>> A PM domain managed by genpd may support multiple idlestates. During >>> genpd_power_off() a genpd governor may be asked to select one of the >>> idlestates based upon the dev PM QoS constraints, for example. >>> >>> However, there is a problem with the behaviour around this in genpd. More >>> precisely, a parent-domain is allowed to be powered off, no matter of what >>> idlestate that has been selected for the child-domain. >>> >>> So far, we have not received any reports about errors from the current >>> behaviour. However, there is an STMicro platform that is being worked on, >>> which can't cope with this. >> >> Could you please provide some technical info about why STMicro platform >> can't cope with that? > > There is a parent domain with one power-off state. The parent domain > has a few devices attached to it, which means they need to be managed > to together. The parent domain is controlling a shared power rail. > > The child domain, which has multiple idle states to choose from, also > has some devices attached to it. The child domain is controlling a > system clock, but also relies on the shared power rail that is managed > by the parent domain. > > Obviously, these idle states are managed by firmware. > > I hope that made it a bit more clear?
Yes, I see now what this patch does.
So "deepest state" in the code's comment means powered off state. Maybe the comment could clarify it better a tad.
- * The children must be in their deepest states to allow the parent to + * The children must be in their deepest (powered-off) states to allow the parent to
| |