On Tuesday, July 25, 2017 07:03:36 AM Huaisheng HS1 Ye wrote: > Hi Srinivas, > Your idea is great, but your patch at cpufreq.c will force all platforms to > use scaling_cur_freq as first choice when userspace wants to access > cpuinfo_cur_freq. It is ok for intel x86 platfrom but hard to say with other > platforms. > I modified it like that, it looks more reasonable. How about that? > > Hi Rafael, > Deleting "get" function pointer within intel_pstate would lead to sysfs > interface cpuinfo_cur_freq disappearing, because of > cpufreq_add_dev_interface will check "cpufreq_driver->get" for it.
Which is exactly what I want. cpuinfo_cur_freq is bogus for intel_pstate and it should have never been exported for this driver. > Perhaps just return 0 with in intel_pstate_get would be a workaround for this > issue, how about it? > > I have tested this patch based on Purley platform, both Hardware and Software > P-states works correct, we could get accurate and same frequency from > cpuinfo_cur_freq and scaling_cur_freq. But this is not correct. These two attributes should not be expected to always return the same value. Thanks, Rafael