On 4 September 2014 15:33, Preeti U Murthy <pre...@linux.vnet.ibm.com> wrote: > I think Rafael's point was that since no driver that had implemented the > target_index callback was using it at the time that this patch was > proposed, it was be best to couple the check on existence of stop_cpu > callback with the the check on the kind of cpufreq driver. However > powerpc is also in need of this today and we implement the target_index > callback and find it convenient to use the stop CPU callback.
No, this is what he said.. " 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" " > Rafael, in which case would it not make sense to remove the check on > driver->setpolicy above? > > Besides, I don't understand very well why we had this double check in > the first place. Only if the drivers are in need of the functionality > like stop_cpu, would they have implemented this callback right? If we > are to assume that the drivers which have implemented the target_index > callback should never be needing it, they would not have implemented the > stop CPU callback either. So what was that, which was blatantly wrong > with just having a check on stop_cpu? I did go through the discussion > but did not find a convincing answer to this. The idea was to get something similar to GOV_STOP for setpolicy drivers. But in the end we didn't get to that. What we do in GOV_STOP is stop changing CPUs frequency, but here in stop_cpu() we can stop changing CPUs frequency OR take it to minimum, whatever we want.. As I said earlier, probably we should just do what you did in your patch + some documentation changes. -- 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/
