<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/cpufreq/pcc-cpufreq.c, branch v4.4.35</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>cpufreq: pcc: Enable autoload of pcc-cpufreq for ACPI processors</title>
<updated>2014-11-13T23:16:25+00:00</updated>
<author>
<name>Lenny Szubowicz</name>
<email>lszubowi@redhat.com</email>
</author>
<published>2014-11-13T18:51:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7e7e8fe69820c6fa31395dbbd8e348e3c69cd2a9'/>
<id>7e7e8fe69820c6fa31395dbbd8e348e3c69cd2a9</id>
<content type='text'>
The pcc-cpufreq driver is not automatically loaded on systems where
the platform's power management setting requires this driver.
Instead, on those systems no CPU frequency driver is registered and
active.

Make the autoloading matching criteria for loading the pcc-cpufreq
driver the same as done in acpi-cpufreq by commit c655affbd524d01
("ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq").

x86 CPU frequency drivers are now typically autoloaded by specifying
MODULE_DEVICE_TABLE entries and x86cpu model specific matching.
But pcc-cpufreq was omitted when acpi-cpufreq and other drivers were
changed to use this approach.

Both acpi-cpufreq and pcc-cpufreq depend on a distinct and mutually
exclusive set of ACPI methods which are not directly tied to specific
processor model numbers. Both of these drivers have init routines
which look for their required ACPI methods. As a result, only the
appropriate driver registers as the cpu frequency driver and the other
one ends up being unloaded.

Tested on various systems where acpi-cpufreq, intel_pstate, and
pcc-cpufreq are the expected cpu frequency drivers.

Signed-off-by: Lenny Szubowicz &lt;lszubowi@redhat.com&gt;
Signed-off-by: Joseph Szczypek &lt;joseph.szczypek@hp.com&gt;
Reported-by: Trinh Dao &lt;trinh.dao@hp.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The pcc-cpufreq driver is not automatically loaded on systems where
the platform's power management setting requires this driver.
Instead, on those systems no CPU frequency driver is registered and
active.

Make the autoloading matching criteria for loading the pcc-cpufreq
driver the same as done in acpi-cpufreq by commit c655affbd524d01
("ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq").

x86 CPU frequency drivers are now typically autoloaded by specifying
MODULE_DEVICE_TABLE entries and x86cpu model specific matching.
But pcc-cpufreq was omitted when acpi-cpufreq and other drivers were
changed to use this approach.

Both acpi-cpufreq and pcc-cpufreq depend on a distinct and mutually
exclusive set of ACPI methods which are not directly tied to specific
processor model numbers. Both of these drivers have init routines
which look for their required ACPI methods. As a result, only the
appropriate driver registers as the cpu frequency driver and the other
one ends up being unloaded.

Tested on various systems where acpi-cpufreq, intel_pstate, and
pcc-cpufreq are the expected cpu frequency drivers.

Signed-off-by: Lenny Szubowicz &lt;lszubowi@redhat.com&gt;
Signed-off-by: Joseph Szczypek &lt;joseph.szczypek@hp.com&gt;
Reported-by: Trinh Dao &lt;trinh.dao@hp.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: pcc-cpufreq: Fix wait_event() under spinlock</title>
<updated>2014-09-29T13:35:50+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2014-09-27T19:56:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e65b5ddba84634f31d42dfd86013f4c6be5e9e32'/>
<id>e65b5ddba84634f31d42dfd86013f4c6be5e9e32</id>
<content type='text'>
Fix the following bug introduced by commit 8fec051eea73 (cpufreq:
Convert existing drivers to use cpufreq_freq_transition_{begin|end})
that forgot to move the spin_lock() in pcc_cpufreq_target() past
cpufreq_freq_transition_begin() which calls wait_event():

BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
Preemption disabled at:[&lt;ffffffffa04d74d7&gt;] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq]
[   51.025044]
CPU: 57 PID: 2636 Comm: modprobe Tainted: G            E  3.17.0-default #7
Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000
 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090
 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00
Call Trace:
 [&lt;ffffffff81589dbd&gt;] dump_stack+0x4d/0x90
 [&lt;ffffffff8108e1df&gt;] ___might_sleep+0x10f/0x180
 [&lt;ffffffff8108e298&gt;] __might_sleep+0x48/0xd0
 [&lt;ffffffff8145b905&gt;] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy-&gt;transition_wait, !policy-&gt;transition_ongoing);
 [&lt;ffffffff8108fc99&gt;] ? preempt_count_add+0xb9/0xc0
 [&lt;ffffffffa04d7513&gt;] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&amp;pcc_lock);
 [&lt;ffffffff810e0d0f&gt;] ? update_ts_time_stats+0x7f/0xb0
 [&lt;ffffffff8145be55&gt;] __cpufreq_driver_target+0x85/0x170
 [&lt;ffffffff8145e4c8&gt;] od_check_cpu+0xa8/0xb0
 [&lt;ffffffff8145ef10&gt;] dbs_check_cpu+0x180/0x1d0
 [&lt;ffffffff8145f310&gt;] cpufreq_governor_dbs+0x3b0/0x720
 [&lt;ffffffff8145ebe3&gt;] od_cpufreq_governor_dbs+0x33/0xe0
 [&lt;ffffffff814593d9&gt;] __cpufreq_governor+0xa9/0x210
 [&lt;ffffffff81459fb2&gt;] cpufreq_set_policy+0x1e2/0x2e0
 [&lt;ffffffff8145a6cc&gt;] cpufreq_init_policy+0x8c/0x110
 [&lt;ffffffff8145c9a0&gt;] ? cpufreq_update_policy+0x1b0/0x1b0
 [&lt;ffffffff8108fb99&gt;] ? preempt_count_sub+0xb9/0x100
 [&lt;ffffffff8145c6c6&gt;] __cpufreq_add_dev+0x596/0x6b0
 [&lt;ffffffffa016c608&gt;] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [&lt;ffffffff8145c7ee&gt;] cpufreq_add_dev+0xe/0x10
 [&lt;ffffffff81408e81&gt;] subsys_interface_register+0xc1/0xf0
 [&lt;ffffffff8108fb99&gt;] ? preempt_count_sub+0xb9/0x100
 [&lt;ffffffff8145b3d7&gt;] cpufreq_register_driver+0x117/0x2a0
 [&lt;ffffffffa016c65d&gt;] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
 [&lt;ffffffffa016c608&gt;] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [&lt;ffffffff81000298&gt;] do_one_initcall+0xc8/0x1f0
 [&lt;ffffffff811a731d&gt;] ? __vunmap+0x9d/0x100
 [&lt;ffffffff810eb9a0&gt;] do_init_module+0x30/0x1b0
 [&lt;ffffffff810edfa6&gt;] load_module+0x686/0x710
 [&lt;ffffffff810ebb20&gt;] ? do_init_module+0x1b0/0x1b0
 [&lt;ffffffff810ee1db&gt;] SyS_init_module+0x9b/0xc0
 [&lt;ffffffff8158f7a9&gt;] system_call_fastpath+0x16/0x1b

Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
Reported-and-tested-by: Mike Galbraith &lt;umgwanakikbuti@gmail.com&gt;
Cc: 3.15+ &lt;stable@vger.kernel.org&gt; # 3.15+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the following bug introduced by commit 8fec051eea73 (cpufreq:
Convert existing drivers to use cpufreq_freq_transition_{begin|end})
that forgot to move the spin_lock() in pcc_cpufreq_target() past
cpufreq_freq_transition_begin() which calls wait_event():

BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
Preemption disabled at:[&lt;ffffffffa04d74d7&gt;] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq]
[   51.025044]
CPU: 57 PID: 2636 Comm: modprobe Tainted: G            E  3.17.0-default #7
Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000
 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090
 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00
Call Trace:
 [&lt;ffffffff81589dbd&gt;] dump_stack+0x4d/0x90
 [&lt;ffffffff8108e1df&gt;] ___might_sleep+0x10f/0x180
 [&lt;ffffffff8108e298&gt;] __might_sleep+0x48/0xd0
 [&lt;ffffffff8145b905&gt;] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy-&gt;transition_wait, !policy-&gt;transition_ongoing);
 [&lt;ffffffff8108fc99&gt;] ? preempt_count_add+0xb9/0xc0
 [&lt;ffffffffa04d7513&gt;] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&amp;pcc_lock);
 [&lt;ffffffff810e0d0f&gt;] ? update_ts_time_stats+0x7f/0xb0
 [&lt;ffffffff8145be55&gt;] __cpufreq_driver_target+0x85/0x170
 [&lt;ffffffff8145e4c8&gt;] od_check_cpu+0xa8/0xb0
 [&lt;ffffffff8145ef10&gt;] dbs_check_cpu+0x180/0x1d0
 [&lt;ffffffff8145f310&gt;] cpufreq_governor_dbs+0x3b0/0x720
 [&lt;ffffffff8145ebe3&gt;] od_cpufreq_governor_dbs+0x33/0xe0
 [&lt;ffffffff814593d9&gt;] __cpufreq_governor+0xa9/0x210
 [&lt;ffffffff81459fb2&gt;] cpufreq_set_policy+0x1e2/0x2e0
 [&lt;ffffffff8145a6cc&gt;] cpufreq_init_policy+0x8c/0x110
 [&lt;ffffffff8145c9a0&gt;] ? cpufreq_update_policy+0x1b0/0x1b0
 [&lt;ffffffff8108fb99&gt;] ? preempt_count_sub+0xb9/0x100
 [&lt;ffffffff8145c6c6&gt;] __cpufreq_add_dev+0x596/0x6b0
 [&lt;ffffffffa016c608&gt;] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [&lt;ffffffff8145c7ee&gt;] cpufreq_add_dev+0xe/0x10
 [&lt;ffffffff81408e81&gt;] subsys_interface_register+0xc1/0xf0
 [&lt;ffffffff8108fb99&gt;] ? preempt_count_sub+0xb9/0x100
 [&lt;ffffffff8145b3d7&gt;] cpufreq_register_driver+0x117/0x2a0
 [&lt;ffffffffa016c65d&gt;] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
 [&lt;ffffffffa016c608&gt;] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [&lt;ffffffff81000298&gt;] do_one_initcall+0xc8/0x1f0
 [&lt;ffffffff811a731d&gt;] ? __vunmap+0x9d/0x100
 [&lt;ffffffff810eb9a0&gt;] do_init_module+0x30/0x1b0
 [&lt;ffffffff810edfa6&gt;] load_module+0x686/0x710
 [&lt;ffffffff810ebb20&gt;] ? do_init_module+0x1b0/0x1b0
 [&lt;ffffffff810ee1db&gt;] SyS_init_module+0x9b/0xc0
 [&lt;ffffffff8158f7a9&gt;] system_call_fastpath+0x16/0x1b

Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
Reported-and-tested-by: Mike Galbraith &lt;umgwanakikbuti@gmail.com&gt;
Cc: 3.15+ &lt;stable@vger.kernel.org&gt; # 3.15+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}</title>
<updated>2014-03-26T15:41:41+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2014-03-24T08:05:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8fec051eea736ec1d8060a2c8766bf3a6b32c3d2'/>
<id>8fec051eea736ec1d8060a2c8766bf3a6b32c3d2</id>
<content type='text'>
CPUFreq core has new infrastructure that would guarantee serialized calls to
target() or target_index() callbacks. These are called
cpufreq_freq_transition_begin() and cpufreq_freq_transition_end().

This patch converts existing drivers to use these new set of routines.

Reviewed-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CPUFreq core has new infrastructure that would guarantee serialized calls to
target() or target_index() callbacks. These are called
cpufreq_freq_transition_begin() and cpufreq_freq_transition_end().

This patch converts existing drivers to use these new set of routines.

Reviewed-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: send new set of notification for transition failures</title>
<updated>2014-01-06T00:43:44+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2013-12-02T05:34:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ab1b1c4e8223f9ee66aa93aaf64c36e77cadffac'/>
<id>ab1b1c4e8223f9ee66aa93aaf64c36e77cadffac</id>
<content type='text'>
In the current code, if we fail during a frequency transition, we
simply send the POSTCHANGE notification with the old frequency. This
isn't enough.

One of the core users of these notifications is the code responsible
for keeping loops_per_jiffy aligned with frequency changes. And mostly
it is written as:

	if ((val == CPUFREQ_PRECHANGE  &amp;&amp; freq-&gt;old &lt; freq-&gt;new) ||
	    (val == CPUFREQ_POSTCHANGE &amp;&amp; freq-&gt;old &gt; freq-&gt;new)) {
		update-loops-per-jiffy...
	}

So, suppose we are changing to a higher frequency and failed during
transition, then following will happen:
- CPUFREQ_PRECHANGE notification with freq-new &gt; freq-old
- CPUFREQ_POSTCHANGE notification with freq-new == freq-old

The first one will update loops_per_jiffy and second one will do
nothing. Even if we send the 2nd notification by exchanging values of
freq-new and old, some users of these notifications might get
unstable.

This can be fixed by simply calling cpufreq_notify_post_transition()
with error code and this routine will take care of sending
notifications in the correct order.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
[rjw: Folded 3 patches into one, rebased unicore2 changes]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the current code, if we fail during a frequency transition, we
simply send the POSTCHANGE notification with the old frequency. This
isn't enough.

One of the core users of these notifications is the code responsible
for keeping loops_per_jiffy aligned with frequency changes. And mostly
it is written as:

	if ((val == CPUFREQ_PRECHANGE  &amp;&amp; freq-&gt;old &lt; freq-&gt;new) ||
	    (val == CPUFREQ_POSTCHANGE &amp;&amp; freq-&gt;old &gt; freq-&gt;new)) {
		update-loops-per-jiffy...
	}

So, suppose we are changing to a higher frequency and failed during
transition, then following will happen:
- CPUFREQ_PRECHANGE notification with freq-new &gt; freq-old
- CPUFREQ_POSTCHANGE notification with freq-new == freq-old

The first one will update loops_per_jiffy and second one will do
nothing. Even if we send the 2nd notification by exchanging values of
freq-new and old, some users of these notifications might get
unstable.

This can be fixed by simply calling cpufreq_notify_post_transition()
with error code and this routine will take care of sending
notifications in the correct order.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
[rjw: Folded 3 patches into one, rebased unicore2 changes]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'pm-cpufreq'</title>
<updated>2013-10-28T00:29:34+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-10-28T00:29:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=93658cb8597ab76655220be43d3d7f74c66e9e4e'/>
<id>93658cb8597ab76655220be43d3d7f74c66e9e4e</id>
<content type='text'>
* pm-cpufreq: (167 commits)
  cpufreq: create per policy rwsem instead of per CPU cpu_policy_rwsem
  intel_pstate: Add Baytrail support
  intel_pstate: Refactor driver to support CPUs with different MSR layouts
  cpufreq: Implement light weight -&gt;target_index() routine
  PM / OPP: rename header to linux/pm_opp.h
  PM / OPP: rename data structures to dev_pm equivalents
  PM / OPP: rename functions to dev_pm_opp*
  cpufreq / governor: Remove fossil comment
  cpufreq: exynos4210: Use the common clock framework to set APLL clock rate
  cpufreq: exynos4x12: Use the common clock framework to set APLL clock rate
  cpufreq: Detect spurious invocations of update_policy_cpu()
  cpufreq: pmac64: enable cpufreq on iMac G5 (iSight) model
  cpufreq: pmac64: provide cpufreq transition latency for older G5 models
  cpufreq: pmac64: speed up frequency switch
  cpufreq: highbank-cpufreq: Enable Midway/ECX-2000
  exynos-cpufreq: fix false return check from "regulator_set_voltage"
  speedstep-centrino: Remove unnecessary braces
  acpi-cpufreq: Add comment under ACPI_ADR_SPACE_SYSTEM_IO case
  cpufreq: arm-big-little: use clk_get instead of clk_get_sys
  cpufreq: exynos: Show a list of available frequencies
  ...

Conflicts:
	drivers/devfreq/exynos/exynos5_bus.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* pm-cpufreq: (167 commits)
  cpufreq: create per policy rwsem instead of per CPU cpu_policy_rwsem
  intel_pstate: Add Baytrail support
  intel_pstate: Refactor driver to support CPUs with different MSR layouts
  cpufreq: Implement light weight -&gt;target_index() routine
  PM / OPP: rename header to linux/pm_opp.h
  PM / OPP: rename data structures to dev_pm equivalents
  PM / OPP: rename functions to dev_pm_opp*
  cpufreq / governor: Remove fossil comment
  cpufreq: exynos4210: Use the common clock framework to set APLL clock rate
  cpufreq: exynos4x12: Use the common clock framework to set APLL clock rate
  cpufreq: Detect spurious invocations of update_policy_cpu()
  cpufreq: pmac64: enable cpufreq on iMac G5 (iSight) model
  cpufreq: pmac64: provide cpufreq transition latency for older G5 models
  cpufreq: pmac64: speed up frequency switch
  cpufreq: highbank-cpufreq: Enable Midway/ECX-2000
  exynos-cpufreq: fix false return check from "regulator_set_voltage"
  speedstep-centrino: Remove unnecessary braces
  acpi-cpufreq: Add comment under ACPI_ADR_SPACE_SYSTEM_IO case
  cpufreq: arm-big-little: use clk_get instead of clk_get_sys
  cpufreq: exynos: Show a list of available frequencies
  ...

Conflicts:
	drivers/devfreq/exynos/exynos5_bus.c
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: pcc: don't initialize part of policy set by core</title>
<updated>2013-10-15T22:50:31+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2013-10-03T14:58:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6b67ca322d409003c29e119f8c8beeecd5785e20'/>
<id>6b67ca322d409003c29e119f8c8beeecd5785e20</id>
<content type='text'>
Many common initializations of struct policy are moved to core now and hence
this driver doesn't need to do it. This patch removes such code.

Most recent of those changes is to call -&gt;get() in the core after calling
-&gt;init().

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Many common initializations of struct policy are moved to core now and hence
this driver doesn't need to do it. This patch removes such code.

Most recent of those changes is to call -&gt;get() in the core after calling
-&gt;init().

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: add new routine cpufreq_verify_within_cpu_limits()</title>
<updated>2013-10-15T22:50:23+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2013-10-02T08:43:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=be49e3465f222b4b796be8a21d14afbfd8f5d20f'/>
<id>be49e3465f222b4b796be8a21d14afbfd8f5d20f</id>
<content type='text'>
Most of the users of cpufreq_verify_within_limits() calls it for
limiting with min/max from policy-&gt;cpuinfo. We can make that code
simple by introducing another routine which will do this for them
automatically.

This patch adds another routine cpufreq_verify_within_cpu_limits()
and updates others to use it.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Acked-by: Dirk Brandewie &lt;dirk.j.brandewie@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most of the users of cpufreq_verify_within_limits() calls it for
limiting with min/max from policy-&gt;cpuinfo. We can make that code
simple by introducing another routine which will do this for them
automatically.

This patch adds another routine cpufreq_verify_within_cpu_limits()
and updates others to use it.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Acked-by: Dirk Brandewie &lt;dirk.j.brandewie@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pcc_freq: convert acpi_get_handle() to acpi_has_method()</title>
<updated>2013-09-23T23:37:55+00:00</updated>
<author>
<name>Zhang Rui</name>
<email>rui.zhang@intel.com</email>
</author>
<published>2013-09-03T00:31:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7ca9b574915a17a588db37c5635890fe660ef7e9'/>
<id>7ca9b574915a17a588db37c5635890fe660ef7e9</id>
<content type='text'>
acpi_has_method() is a new ACPI API introduced to check
the existence of an ACPI control method.

It can be used to replace acpi_get_handle() in the case that
1. the calling function doesn't need the ACPI handle of the control method.
and
2. the calling function doesn't care the reason why the method is unavailable.

Convert acpi_get_handle() to acpi_has_method()
in drivers/cpufreq/pcc_freq.c in this patch.

Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
acpi_has_method() is a new ACPI API introduced to check
the existence of an ACPI control method.

It can be used to replace acpi_get_handle() in the case that
1. the calling function doesn't need the ACPI handle of the control method.
and
2. the calling function doesn't care the reason why the method is unavailable.

Convert acpi_get_handle() to acpi_has_method()
in drivers/cpufreq/pcc_freq.c in this patch.

Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: Drop the owner field from struct cpufreq_driver</title>
<updated>2013-08-10T01:24:47+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2013-08-06T17:23:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=adc97d6a735dbb1e94cb4f1bf0b55f258b349941'/>
<id>adc97d6a735dbb1e94cb4f1bf0b55f258b349941</id>
<content type='text'>
We don't need to set .owner = THIS_MODULE any more in cpufreq drivers
as this field isn't used any more by the cpufreq core.

This patch removes it and updates all dependent drivers accordingly.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We don't need to set .owner = THIS_MODULE any more in cpufreq drivers
as this field isn't used any more by the cpufreq core.

This patch removes it and updates all dependent drivers accordingly.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error cases</title>
<updated>2013-06-24T11:26:39+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2013-06-19T08:53:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f77f146599146ddc19e0454170c06ddff75bc81f'/>
<id>f77f146599146ddc19e0454170c06ddff75bc81f</id>
<content type='text'>
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e
either both should be called or both shouldn't be.

In case we have started PRECHANGE notifier and found an error, we
must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee
that the sequence of calling notifiers is complete.

This patch fixes it.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e
either both should be called or both shouldn't be.

In case we have started PRECHANGE notifier and found an error, we
must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee
that the sequence of calling notifiers is complete.

This patch fixes it.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
