Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH V2 1/2] cpufreq: suspend governors on system suspend/hibernate | Date | Wed, 27 Nov 2013 15:26:49 +0100 |
| |
On Wednesday, November 27, 2013 08:26:00 AM Viresh Kumar wrote: > On 27 November 2013 01:48, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Tuesday, November 26, 2013 08:39:02 PM Pavel Machek wrote: > >> So... we freeze frequencies in whatever state they are, yes? > > Better go through the V3 of this patchset: > > https://lkml.org/lkml/2013/11/25/838 > > We are giving drivers and opportunity to set core to whatever frequency they > want before suspending. > > > Yes. The idea was to do that after suspending devices in which case it wouldn't > > matter so much. But Viresh always has to complicate things. > > :) > > Its complicated by the kind of designs we have for our hardware. We tried the > noirq callbacks and it worked atleast for Nishanth, who reported the problem > initially. But the problem started when drivers wanted to change their > frequencies before suspending and that can't happen in noirq place..
This way you end up with a fix that may introduce other issues. Which is kind of fine before a merge window, but not so much after one. So at this point it's better to fix things that may be fixed without introducing those other issues *first* and then go for a more intrusive change that will cover more cases.
> I had another idea but then left it thinking that it might be even more > complicated :) > > What about both dpm_suspend_noirq and dpm_suspend callbacks. Drivers > will change freq in dpm_suspend_noirq and dpm_suspend will stop governors? > > But the question is can governors try another frequency at that time? > i.e. override whatever is configured by drivers? > > >> Should we go to some specific frequency? > > > > If that is done where it is done, yes, we should. > > You meant dpm_suspend() here, right?
Yes.
Thanks!
-- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
| |