On Tue, May 31, 2016 at 11:00:11AM +0530, Viresh Kumar wrote: > 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 ?
I'm still concerned that a platform owner may use this and accept suboptimal perf/power because they aren't aware their cpufreq driver is not fully compliant. But I agree it'd be better to have it work as well as it can. I will make the change. Maybe a warning message can be added when schedutil initializes if resolve_freq is not supported. thanks, Steve