On Wednesday, July 19, 2017 12:24:06 PM Viresh Kumar wrote: > On 18-07-17, 22:34, Leonard Crestez wrote: > > The semantics of scaling_cur_freq and cpuinfo_cur_freq are not very > > clear to me. > > cpuinfo_cur_freq reads the frequency right from hardware all the time > and so can be slow. It can only be read by root if I remember > correctly. > > Whereas scaling_cur_freq tries to read the cached frequency. But it > has changed a bit with the below mentioned patch. > > > In my particular case I need to check cpuinfo_cur_freq because this is > > what ends up returning the rate of the arm clk. Otherwise > > scaling_cur_freq just returns policy->cur > > Yeah, we may actually need to use cpuinfo_cur_freq as that is what > ends up giving the real freq. > > > unless the driver has a > > setpolicy function (I don't understand that condition). > > That's because the core doesn't know the cached freq for setpolicy > drivers and so we need to call the ->get() callback. But for non > setpolicy drivers, core already has the cached value. Please remember that cpuinfo_cur_freq may not be present. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
