On 08-04-16, 00:05, Rafael J. Wysocki wrote: > On Thursday, April 07, 2016 05:35:03 PM Viresh Kumar wrote:
> > That's *ugly* and it works by chance, unless I am misreading it > > completely. > > I'm assuming that what you mean by "ugly" here is "not really > straightforward", > which I agree with, Yeah. > but then it is really disappointing to see comments like > that from you about the code that you helped to write. I was just trying to say that this isn't how I feel it should be done. :( > Moreover, runtime CPU offline *also* doesn't have to run the governor > exit/init > for the same reason why the policy directory doesn't have to be removed on > CPU offline: it is just pointless to do that. The governor has been stopped > already and it won't do anything more. The only problem here is to prevent > governor tunable sysfs attributes from triggering actions in that state, > but that shouldn't be too difficult to arrange for. If that's done, Isn't that already guaranteed as userspace should have been frozen by by the time we reach cpufreq_suspend()? > cpufreq_suspended can be dropped, modulo changing cpufreq_start_governor() > to return immediately if the governor has been started already. > > And if something else is needed to protect driver callbacks from being invoked > outside of the suspend-resume path, a more robust mechanism has to be added > for that. > > But in the meantime, I'd like to address the fast switch problem first and > then you're free to clean up things on top of that. Or I will clean them up > if I have the time. Okay.. -- viresh
