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. -- viresh -- 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
