On Wednesday, November 27, 2013 08:26:00 AM Viresh Kumar wrote: > On 27 November 2013 01:48, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
