On 30-05-16, 08:31, Steve Muckle wrote: > My goal here was to have the system operate in this case in a manner > that is obviously not optimized (running at fmax), so the platform owner > realizes that the cpufreq driver doesn't fully support the schedutil > governor. > > I was originally going to just return an error code but that also means > having to check for it which would be nice to avoid if possible on this > fast path.
Okay, I get what you are saying. But all we are doing here is to make things fast by not sending IPIs, etc. That should *not* lead to a behavior where the frequency stays at MAX all the time even if the driver doesn't provide this callback or the freq-table. If we just return the target_freq in this case instead of UINT_MAX, the platform may eventually have some unnecessary IPIs, wakeups, etc, but its frequency will still be switched properly. Wouldn't that be a better choice ? -- viresh