On 19 March 2014 19:49, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> That said, for the intel_pstate case ->stop() as proposed by Dirk is > demonstrably > sufficient and there are no other ->setpolicy drivers in sight wanting or > needing > anything else. > > So to me, (1) the new ->stop() should *only* be called for ->setpolicy > drivers, > because the purpose of it should be to "allow ->setpolicy drivers to do what > the > GOV_STOP will do for regular drivers" as you put it above, and (2) some code > in > the original intel_pstate's ->exit() may/should stay in there (instead of > being > moved to the new ->stop()), which is the only possibly remaining issue here. > > The whole discussion about possibly re-using ->stop() for ->target drivers > goes > in a totally wrong direction, because *if* ->target drivers need a new > callback > to be executed around where ->stop() is called for ->setpolicy drivers, *then* > that has to be a *different* callback. > > And by the way, ->get() in fact has a different meaning for ->setpolicy > drivers, > so it would be good to consider logical separation of ->setpolicy and ->target > drivers so that each kind has its own separate set of callbacks with no > overlaps. > That would make it easier to avoid breakage resulting from changes made with > ->setpolicy drivers that also affect ->target drivers in unpredictable ways > and > the other way around. Okay, I have picked up a very old thread but it looks more sensible to start replying here.. Preeti (Cc'd) wants to do something similar, i.e. reduce freq of a core before it goes down. And the driver is probably: drivers/cpufreq/powernv-cpufreq.c, which is ->target() type. Now should we reuse the same callback ->stop_cpu() or implement a new one? I don't know if adding a new callback would be a good idea here.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/