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!