Hi Rafael,
I am almost done with cleanup of drivers and am back at cpufreq core.. :) I got to this structure: struct cpufreq_real_policy;
And I am not able to understand what's the need for this structure? Can you let me know? Before I try to get rid of it :)
-- viresh
On Monday, August 26, 2013 08:00:52 PM Viresh Kumar wrote:
Hi Rafael,
Hi,
I am almost done with cleanup of drivers and am back at cpufreq core.. :) I got to this structure: struct cpufreq_real_policy;
And I am not able to understand what's the need for this structure? Can you let me know? Before I try to get rid of it :)
Honestly, I don't remember from the top of my head.
Thanks, Rafael
2013/8/26 Rafael J. Wysocki rjw@sisk.pl:
On Monday, August 26, 2013 08:00:52 PM Viresh Kumar wrote:
Hi Rafael,
Hi,
I am almost done with cleanup of drivers and am back at cpufreq core.. :) I got to this structure: struct cpufreq_real_policy;
And I am not able to understand what's the need for this structure? Can you let me know? Before I try to get rid of it :)
Honestly, I don't remember from the top of my head.
So far as I know, it stores some user's config and cpufreq_update_policy() bases on the data in the struct to start a new policy. Cpu thermal driver (/driver/thermal/cpu_cooling.c)also will its value to update freq policy when receive a cpufreq policy adjust notification.
Thanks, Rafael
-- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26 August 2013 20:53, Lan Tianyu lantianyu1986@gmail.com wrote:
So far as I know, it stores some user's config and cpufreq_update_policy() bases on the data in the struct to start a new policy. Cpu thermal driver (/driver/thermal/cpu_cooling.c)also will its value to update freq policy when receive a cpufreq policy adjust notification.
Yeah, but how are these different from policy->min/max/policy/governor? Why do we need to replicate this information?
2013/8/27 Viresh Kumar viresh.kumar@linaro.org:
On 26 August 2013 20:53, Lan Tianyu lantianyu1986@gmail.com wrote:
So far as I know, it stores some user's config and cpufreq_update_policy() bases on the data in the struct to start a new policy. Cpu thermal driver (/driver/thermal/cpu_cooling.c)also will its value to update freq policy when receive a cpufreq policy adjust notification.
Yeah, but how are these different from policy->min/max/policy/governor? Why do we need to replicate this information?
From my understanding.policy->min/max may be modified by some drivers
but the user_policy only store user space config and should not be changed by other reason. :)
On Tuesday, August 27, 2013 10:04:52 PM Lan Tianyu wrote:
2013/8/27 Viresh Kumar viresh.kumar@linaro.org:
On 26 August 2013 20:53, Lan Tianyu lantianyu1986@gmail.com wrote:
So far as I know, it stores some user's config and cpufreq_update_policy() bases on the data in the struct to start a new policy. Cpu thermal driver (/driver/thermal/cpu_cooling.c)also will its value to update freq policy when receive a cpufreq policy adjust notification.
Yeah, but how are these different from policy->min/max/policy/governor? Why do we need to replicate this information?
From my understanding.policy->min/max may be modified by some drivers but the user_policy only store user space config and should not be changed by other reason. :)
Yes, that was the original idea IIRC, so separate user settings from stuff that may be changed internally by the kernel.
Thanks, Rafael
On 28 August 2013 02:50, Rafael J. Wysocki rjw@sisk.pl wrote:
On Tuesday, August 27, 2013 10:04:52 PM Lan Tianyu wrote:
From my understanding.policy->min/max may be modified by some drivers but the user_policy only store user space config and should not be changed by other reason. :)
Yes, that was the original idea IIRC, so separate user settings from stuff that may be changed internally by the kernel.
Yeah, that's what I understood too now.. Anyway I am going to do some core cleanups now, drivers are mostly done and will see if something can be done to get rid of them... Otherwise will keep them as is.
linaro-kernel@lists.linaro.org