On 12/18/2013 06:33 PM, Rafael J. Wysocki wrote:
> On Wednesday, December 18, 2013 04:35:04 PM Jason Baron wrote:
>> On 12/18/2013 04:38 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, December 18, 2013 08:31:02 PM Jason Baron wrote:
>>>> When configuring a default governor (via CONFIG_CPU_FREQ_DEFAULT_*) with the
>>>> 'intel_pstate' driver, I found that the default is not honored. For example,
>>>> configure 'CONFIG_CPU_FREQ_GOV_PERFORMANCE', and then do:
>>> intel_pstate doesn't use any cpufreq governors, so all of this is pointless
>>> for that particular driver anyway.
>>>
>>> Thanks!
>>>
>> Ok, but if I look at 'intel_pstate', I see a 'set_policy' call that does different
>> things if the policy is 'performance' vs. 'powersave'. Same for the 'longrun'
>> driver. So yes, they don't use the 'governors', but changing the governors
>> at runtime does appear to change change how they behave.
> OK, so you want the initial policy to be set in accordance with the
> CONFIG_CPU_FREQ_DEFAULT_* setting. That makes sense, although it is not
> immediately clear from the patch changelog.
>
> That said the change in the patch looks kind of overly complicated.
> What about adding something like this instead?
Agreed - this is better. Will you just pull the below patch, or should
I re-post with a better changelog?
Thanks,
-Jason
> + if (cpufreq_driver->setpolicy) {
> + unsigned int ret;
> +
> + /* Use the default policyt if it is valid. */
> + if (!cpufreq_parse_governor(policy->governor->name, &ret, NULL))
> + new_policy.policy = ret;
> + }
>
> Rafael
>
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
