talos-op-linux/drivers/cpufreq/cpufreq.c, branch v4.4.4

cpufreq: use last policy after online for drivers with ->setpolicy

2015-12-02T22:50:33+00:00

For cpufreq drivers which use setpolicy interface, after offline->online the policy is set to default. This can be reproduced by setting the default policy of intel_pstate or longrun to ondemand and then change to "performance". After offline and online, the setpolicy will be called with the policy=ondemand. For drivers using governors this condition is handled by storing last_governor, during offline and restoring during online. The same should be done for drivers using setpolicy interface. Storing last_policy during offline and restoring during online. Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki

cpufreq: Always remove sysfs cpuX/cpufreq link on ->remove_dev()

2015-11-23T21:49:42+00:00

Subsys interface's ->remove_dev() is called when the cpufreq driver is unregistering or the CPU is getting physically removed. We keep removing the cpuX/cpufreq link for all CPUs except the last one, which is a mistake as all CPUs contain a link now. Because of this, one CPU from each policy will still contain a link (to an already removed policyX directory), after the cpufreq driver is unregistered. Fix that by removing the link first and then only see if the policy is required to be freed. That will make sure that no links are left out. Fixes: 96bdda61f58b ("cpufreq: create cpu/cpufreq/policyX directories") Reported-and-tested-by: Srinivas Pandruvada Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: postfix policy directory with the first CPU in related_cpus

2015-10-28T08:21:12+00:00

The sysfs policy directory is postfixed currently with the CPU number for which the policy was created, which isn't necessarily the first CPU in related_cpus mask. To make it more consistent and predictable, lets postfix the policy with the first cpu in related-cpus mask. Suggested-by: Saravana Kannan Signed-off-by: Viresh Kumar Reviewed-by: Saravana Kannan Signed-off-by: Rafael J. Wysocki

cpufreq: create cpu/cpufreq/policyX directories

2015-10-28T08:21:12+00:00

The cpufreq sysfs interface had been a bit inconsistent as one of the CPUs for a policy had a real directory within its sysfs 'cpuX' directory and all other CPUs had links to it. That also made the code a bit complex as we need to take care of moving the sysfs directory if the CPU containing the real directory is getting physically hot-unplugged. Solve this by creating 'policyX' directories (per-policy) in /sys/devices/system/cpu/cpufreq/ directory, where X is the CPU for which the policy was first created. This also removes the need of keeping kobj_cpu and we can remove it now. Suggested-by: Saravana Kannan Signed-off-by: Viresh Kumar Reviewed-by: Saravana Kannan Acked-by: is more of a general agreement from the person that he is Reviewed-by: is a more strict tag and implies that the reviewer has Signed-off-by: Rafael J. Wysocki

cpufreq: remove cpufreq_sysfs_{create|remove}_file()

2015-10-28T08:21:12+00:00

They don't do anything special now, remove the unnecessary wrapper. Reviewed-by: Saravana Kannan Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: create cpu/cpufreq at boot time

2015-10-28T08:21:12+00:00

Later patches will need to create policy specific directories in /sys/devices/system/cpu/cpufreq/ directory and so the cpufreq directory wouldn't be ever empty. And so no fun creating/destroying it on need basis anymore. Create it once on system boot. Reviewed-by: Saravana Kannan Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Use cpumask_copy instead of cpumask_or to copy a mask

2015-10-28T08:21:11+00:00

->related_cpus is empty at this point of time and copying ->cpus to it or orring ->related_cpus with ->cpus would result in the same value. But cpumask_copy makes it rather clear. Reviewed-by: Saravana Kannan Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Drop redundant check for inactive policies

2015-10-14T00:30:28+00:00

We just made sure policy->cpu is online and this check will always fail as the policy is active. Drop it. Signed-off-by: Viresh Kumar Acked-by: Saravana Kannan Signed-off-by: Rafael J. Wysocki

cpufreq: prevent lockup on reading scaling_available_frequencies

2015-10-08T19:47:56+00:00

When scaling_available_frequencies is read on an offlined cpu, then either lockup or junk values are displayed. This is caused by freed freq_table, which policy is using. Signed-off-by: Srinivas Pandruvada Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: acpi-cpufreq: Use cpufreq_cpu_get_raw() in ->get()

2015-09-16T00:17:49+00:00

cpufreq_cpu_get() called by get_cur_freq_on_cpu() is overkill, because the ->get() callback is always invoked in a context in which all of the conditions checked by cpufreq_cpu_get() are guaranteed to be satisfied. Use cpufreq_cpu_get_raw() instead of it and drop the corresponding cpufreq_cpu_put() from get_cur_freq_on_cpu(). Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar