On 26 September 2013 00:07, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > So the problem is real, but the fix seems to be of a "quick and dirty" kind. Hmm.. > First of all, it looks like we need a clear "begin transition" call that > I suppose drivers should execute from their .target() methods once they have > decided to do a transition. That would increment the "ongoing" counter etc. > > Second, we need a corresponding "end transition" call that would be executed > whenever appropriate from the driver's perspective. Hmm.. > Clearly, these two things should be independent of the notifiers and the > notifications should only be done between "begin transition" and "end > transition" and only by whoever called the "begin transition" to start with. So, we need to have begin/end calls in cpufreq_out_of_sync() as well? As that is sending notifications.. > Now, question is what should happen if "begin transition" is called when > the previous transition hasn't been completed yet, should it block or should > it fail? There seem to be arguments for both, but I suppose blocking would be > easier to implement. Hmm.. I will repost this once my other patches are in now.. as that will change ->target() routine for multiple drivers and things would be simple to fix then.. -- 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
