On 03/04/2016 03:18 PM, Rafael J. Wysocki wrote: > In fact, the mechanism may be relatively simple if I'm not mistaken. > > In the "fast switch" case, the governor may spawn a work item that > will just execute cpufreq_get() on policy->cpu. That will notice that > policy->cur is different from the real current frequency and will > re-adjust. > > Of course, cpufreq_driver_fast_switch() will need to be modified so it > doesn't update policy->cur then perhaps with a comment that the > governor using it will be responsible for that. > > And the governor will need to avoid spawning that work item too often > (basically, if one has been spawned already and hasn't completed, no > need to spawn a new one, and maybe rate-limit it?), but all that looks > reasonably straightforward. It is another option though definitely a compromise. The semantics seem different since you'd potentially have multiple freq changes before a single notifier went through, so stuff might still break. The fast path would also be more expensive given the workqueue activity that could translate into additional task wakeups. Honestly I wonder if it's better to just try the "no notifiers with fast drivers" approach to start. The notifiers could always be added if platform owners complain that they absolutely require them. thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
