On Wed, 2017-07-12 at 13:36 +0200, Rafael J. Wysocki wrote: > On Wed, Jul 12, 2017 at 1:29 PM, Leonard Crestez > <leonard.crestez@xxxxxxx> wrote: > > > > This checks that the cpufreq driver actually sets the requested > > frequency. > This won't work on modern x86 with APERF/MPERF (see recent commits in > that area). This test should be skipped if the cpu always adjusts it's own frequency dynamically. It should check if scaling_set_speed won't reflect in cpuinfo_cur_freq, but I'm not sure how to do that reliably. I checked with the intel_pstate driver and it's already skipped in this test because no userspace governor is available. This could be a way to check if the CPU supports targetting a precise constant frequency. Or are you saying that cpuinfo_cur_freq in general shouldn't be expected to just return the current frequency but also adjust for time spent in various idle states? It seems to me that if you want to track the current load it might be better to report this through different more explicit mechanism. In particular imx already supports cpuidle states where the arm core clock is turned off and later resumed but this has no effect on cpuinfo_cur_freq. -- Regards, Leonard -- 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
