Messages in this thread | | | From | Ulf Hansson <> | Date | Tue, 8 Jun 2021 16:08:55 +0200 | Subject | Re: [PATCH v2 4/4] PM: domains: Drop/restore performance state votes for devices at system PM |
| |
On Tue, 8 Jun 2021 at 14:53, Stephan Gerhold <stephan@gerhold.net> wrote: > > Hi, > > On Thu, Jun 03, 2021 at 12:20:57PM +0200, Ulf Hansson wrote: > > + Mark Brown, Dmitry Baryshkov > > > > On Thu, 3 Jun 2021 at 11:34, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > Recent changes in genpd drops and restore performance state votes for > > > devices during runtime PM. > > > > > > For the similar reasons, but to avoid the same kind of boilerplate code in > > > device PM callbacks for system sleep in subsystems/drivers, let's drop and > > > restore performance states votes in genpd for the attached devices during > > > system sleep. > > > > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > > > After a second thought, it looks like we maybe should defer to apply > > this final patch of the series. At least until we figured out how to > > address the below issue: > > > > So, I noticed that we have things like "regulator-fixed-domain", that > > uses "required-opps" to enable/disable a regulator through the > > dev_pm_set_performance_state() interface. > > Not directly related to your concern, but related to another discussion > we had recently: To me, this looks mostly like another solution for > voting for performance states without doing full DVFS, also known as > assigned-performance-states [1] or required-opps on devices [2]. :) > > It's just wrapped in a regulator interface here. Actually, if we > implement [2], the regulator-fixed-domain should mostly just become some > sort of simple wrapper around runtime PM for the regulator device, since > the required-opp might be applied automatically then.
Honestly, I am not sure about what the regulator-fixed-domain intends to model, but I assume it's something that fits well to be modelled as a plain regulator, to start with.
Perhaps Mark can chime in and spread some light over this?
> > [1]: https://lore.kernel.org/linux-arm-msm/1622095949-2014-1-git-send-email-rnayak@codeaurora.org/ > [2]: https://lore.kernel.org/linux-arm-msm/YLYV3ov%2FiBffZMg4@gerhold.net/ > > > We likely don't want to drop the performance state internally in genpd > > when genpd_suspend_noirq() gets called, for the corresponding struct > > device for the regulator. > > > > So your concern is that the performance state is dropped during suspend > even though the regulator core thinks the regulator stays enabled?
Yes.
> > I played with regulator-fixed-domain a bit and I would say this is > already broken (unless you rely on one of the side effects I mentioned > in [3]). The power domain gets powered off entirely during system > suspend, and then the performance state won't have any effect either.
Right, I get your point.
Although, this isn't a problem, because the on/off and performance states are today considered as orthogonal in gendp. Well, at least currently until/if we decide to change this.
> > I guess we would need some way to say that this device should only be > managed through runtime PM and never automatically suspended during > system suspend?
Yes!
For the on/off state, genpd uses the system wakeup interface to understand whether the device is used in a wakeup path, see the call to device_wakeup_path() in genpd_finish_suspend(). If that's the case the PM domain stays powered on during system suspend.
Potentially we could use the same interface (or something similar) to support these kinds of cases.
> > Stephan > > [3]: https://lore.kernel.org/linux-pm/YLkOAyydZMnxkEy+@gerhold.net/
Kind regards Uffe
| |