Skip to contentSkip to conversation

sysfs support for scaling_cur_freq in intel_pstate

DISCUSSION Radu Rendec 2 participants 2 messages Aug 5, 2013

lore
Share & tools
lore
#0 lore raw

Hi!

After a recent kernel upgrade on my laptop I noticed that my cpu frequency desktop applet wasn't working anymore. I quickly tracked down the problem to the fact that the new scaling driver was intel_pstate, and it didn't expose scaling_cur_freq in sysfs.

On the other hand, cpuinfo_cur_freq is available, but it's only readable by root. Apparently there are good reasons for keeping it like this. I found an older post about this here:
http://comments.gmane.org/gmane.linux.kernel.cpufreq/7005

However, looking at the code in intel_pstate.c, it seems that intel_pstate_get() (which is the implementation for cpuinfo_cur_freq in sysfs) simply extracts a value out of a larger structure. This seems really harmless and very far away from the reasons why cpuinfo_cur_freq was kept readable by root only.

Looking at cpufreq_add_dev_interface() in cpufreq.c, it seems that one needs to define the "target" field in struct cpufreq_driver in order to have scaling_cur_freq exposed in sysfs.

I think setting "target" to intel_pstate_get() in the definition of intel_pstate_driver would fix my problem, since scaling_cur_freq in sysfs is world readable. Is there any reason for not doing this?

If you reply, please cc my personal address - I'm not subscribed to the list.

Thanks,

Radu Rendec

#1 lore raw

[Adding CCs to linux-pm and Dirk.]

Quoted 38 lines · Radu Rendec

Hi!

After a recent kernel upgrade on my laptop I noticed that my cpu frequency desktop applet wasn't working anymore. I quickly tracked down the problem to the fact that the new scaling driver was intel_pstate, and it didn't expose scaling_cur_freq in sysfs.

On the other hand, cpuinfo_cur_freq is available, but it's only readable by root. Apparently there are good reasons for keeping it like this. I found an older post about this here:
http://comments.gmane.org/gmane.linux.kernel.cpufreq/7005

However, looking at the code in intel_pstate.c, it seems that intel_pstate_get() (which is the implementation for cpuinfo_cur_freq in sysfs) simply extracts a value out of a larger structure. This seems really harmless and very far away from the reasons why cpuinfo_cur_freq was kept readable by root only.

Looking at cpufreq_add_dev_interface() in cpufreq.c, it seems that one needs to define the "target" field in struct cpufreq_driver in order to have scaling_cur_freq exposed in sysfs.

I think setting "target" to intel_pstate_get() in the definition of intel_pstate_driver would fix my problem, since scaling_cur_freq in sysfs is world readable. Is there any reason for not doing this?

If you reply, please cc my personal address - I'm not subscribed to the list.

Thanks,

Radu Rendec

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 2 lines
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.