<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/cpufreq, branch v3.12.14</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/cpufreq?h=v3.12.14</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/cpufreq?h=v3.12.14'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-03-05T16:13:46Z</updated>
<entry>
<title>cpufreq: powernow-k8: Initialize per-cpu data-structures properly</title>
<updated>2014-03-05T16:13:46Z</updated>
<author>
<name>Srivatsa S. Bhat</name>
<email>srivatsa.bhat@linux.vnet.ibm.com</email>
</author>
<published>2014-02-17T10:48:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=493931434ba8f6d2b9b1ea1cc377c22787bb3bd7'/>
<id>urn:sha1:493931434ba8f6d2b9b1ea1cc377c22787bb3bd7</id>
<content type='text'>
commit c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e upstream.

The powernow-k8 driver maintains a per-cpu data-structure called
powernow_data that is used to perform the frequency transitions.
It initializes this data structure only for the policy-&gt;cpu. So,
accesses to this data structure by other CPUs results in various
problems because they would have been uninitialized.

Specifically, if a cpu (!= policy-&gt;cpu) invokes the drivers' -&gt;get()
function, it returns 0 as the KHz value, since its per-cpu memory
doesn't point to anything valid. This causes problems during
suspend/resume since cpufreq_update_policy() tries to enforce this
(0 KHz) as the current frequency of the CPU, and this madness gets
propagated to adjust_jiffies() as well. Eventually, lots of things
start breaking down, including the r8169 ethernet card, in one
particularly interesting case reported by Pierre Ossman.

Fix this by initializing the per-cpu data-structures of all the CPUs
in the policy appropriately.

References: https://bugzilla.kernel.org/show_bug.cgi?id=70311
Reported-by: Pierre Ossman &lt;pierre@ossman.eu&gt;
Signed-off-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.</title>
<updated>2014-01-15T23:31:43Z</updated>
<author>
<name>Dirk Brandewie</name>
<email>dirk.j.brandewie@intel.com</email>
</author>
<published>2014-01-06T18:59:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=625b7e66c2d3c55e00962425a79321a8c257192a'/>
<id>urn:sha1:625b7e66c2d3c55e00962425a79321a8c257192a</id>
<content type='text'>
commit 6cbd7ee10e2842a3d1f9b60abede1c8f3d1f1130 upstream.

KVM environments do not support APERF/MPERF MSRs. intel_pstate cannot
operate without these registers.

The previous validity checks in intel_pstate_msrs_not_valid() are
insufficent in nested KVMs.

References: https://bugzilla.redhat.com/show_bug.cgi?id=1046317
Signed-off-by: Dirk Brandewie &lt;dirk.j.brandewie@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>intel_pstate: Fail initialization if P-state information is missing</title>
<updated>2014-01-09T20:25:13Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-12-31T12:37:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=61f7c17bad20ccb763a35317508e3833f1cd5069'/>
<id>urn:sha1:61f7c17bad20ccb763a35317508e3833f1cd5069</id>
<content type='text'>
commit 98a947abdd54e5de909bebadfced1696ccad30cf upstream.

If pstate.current_pstate is 0 after the initial
intel_pstate_get_cpu_pstates(), this means that we were unable to
obtain any useful P-state information and there is no reason to
continue, so free memory and return an error in that case.

This fixes the following divide error occuring in a nested KVM
guest:

Intel P-state driver initializing.
Intel pstate controlling: cpu 0
cpufreq: __cpufreq_add_dev: -&gt;get() failed
divide error: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: ffff88001ea20000 ti: ffff88001e9bc000 task.ti: ffff88001e9bc000
RIP: 0010:[&lt;ffffffff815c551d&gt;]  [&lt;ffffffff815c551d&gt;] intel_pstate_timer_func+0x11d/0x2b0
RSP: 0000:ffff88001ee03e18  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88001a454348 RCX: 0000000000006100
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88001ee03e38 R08: 0000000000000000 R09: 0000000000000000
R10: ffff88001ea20000 R11: 0000000000000000 R12: 00000c0a1ea20000
R13: 1ea200001ea20000 R14: ffffffff815c5400 R15: ffff88001a454348
FS:  0000000000000000(0000) GS:ffff88001ee00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000006f0
Stack:
 fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100
 ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40
 ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000
Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff81083e9a&gt;] call_timer_fn+0x8a/0x310
 [&lt;ffffffff81083e15&gt;] ? call_timer_fn+0x5/0x310
 [&lt;ffffffff815c5400&gt;] ? pid_param_set+0x130/0x130
 [&lt;ffffffff81084354&gt;] run_timer_softirq+0x234/0x380
 [&lt;ffffffff8107aee4&gt;] __do_softirq+0x104/0x430
 [&lt;ffffffff8107b5fd&gt;] irq_exit+0xcd/0xe0
 [&lt;ffffffff81770645&gt;] smp_apic_timer_interrupt+0x45/0x60
 [&lt;ffffffff8176efb2&gt;] apic_timer_interrupt+0x72/0x80
 &lt;EOI&gt;
 [&lt;ffffffff810e15cd&gt;] ? vprintk_emit+0x1dd/0x5e0
 [&lt;ffffffff81757719&gt;] printk+0x67/0x69
 [&lt;ffffffff815c1493&gt;] __cpufreq_add_dev.isra.13+0x883/0x8d0
 [&lt;ffffffff815c14f0&gt;] cpufreq_add_dev+0x10/0x20
 [&lt;ffffffff814a14d1&gt;] subsys_interface_register+0xb1/0xf0
 [&lt;ffffffff815bf5cf&gt;] cpufreq_register_driver+0x9f/0x210
 [&lt;ffffffff81fb19af&gt;] intel_pstate_init+0x27d/0x3be
 [&lt;ffffffff81761e3e&gt;] ? mutex_unlock+0xe/0x10
 [&lt;ffffffff81fb1732&gt;] ? cpufreq_gov_dbs_init+0x12/0x12
 [&lt;ffffffff8100214a&gt;] do_one_initcall+0xfa/0x1b0
 [&lt;ffffffff8109dbf5&gt;] ? parse_args+0x225/0x3f0
 [&lt;ffffffff81f64193&gt;] kernel_init_freeable+0x1fc/0x287
 [&lt;ffffffff81f638d0&gt;] ? do_early_param+0x88/0x88
 [&lt;ffffffff8174b530&gt;] ? rest_init+0x150/0x150
 [&lt;ffffffff8174b53e&gt;] kernel_init+0xe/0x130
 [&lt;ffffffff8176e27c&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff8174b530&gt;] ? rest_init+0x150/0x150
Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 &lt;49&gt; f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89
RIP  [&lt;ffffffff815c551d&gt;] intel_pstate_timer_func+0x11d/0x2b0
 RSP &lt;ffff88001ee03e18&gt;
---[ end trace f166110ed22cc37a ]---
Kernel panic - not syncing: Fatal exception in interrupt

Reported-and-tested-by: Kashyap Chamarthy &lt;kchamart@redhat.com&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cpufreq: highbank-cpufreq: Enable Midway/ECX-2000</title>
<updated>2013-12-04T19:06:14Z</updated>
<author>
<name>Mark Langsdorf</name>
<email>mark.langsdorf@calxeda.com</email>
</author>
<published>2013-10-01T15:30:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d40fb83efc2285906319649d6897c034831360d0'/>
<id>urn:sha1:d40fb83efc2285906319649d6897c034831360d0</id>
<content type='text'>
commit fbbc5bfb44a22e7a8ef753a1c8dfb448d7ac8b85 upstream.

Calxeda's new ECX-2000 part uses the same cpufreq interface as highbank,
so add it to the driver's compatibility list.

This is a minor change that can safely be applied to the 3.10 and 3.11
stable trees.

Signed-off-by: Mark Langsdorf &lt;mark.langsdorf@calxeda.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>acpi-cpufreq: Fail initialization if driver cannot be registered</title>
<updated>2013-10-25T14:22:47Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-10-25T14:22:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=75c0758137c7ac647927b4b12bb5cfca96a0e4e6'/>
<id>urn:sha1:75c0758137c7ac647927b4b12bb5cfca96a0e4e6</id>
<content type='text'>
Make acpi_cpufreq_init() return error codes when the driver cannot be
registered so that the module doesn't stay useless in memory and so
that acpi_cpufreq_exit() doesn't attempt to unregister things that
have never been registered when the module is unloaded.

Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
</content>
</entry>
<entry>
<title>intel_pstate: Correct calculation of min pstate value</title>
<updated>2013-10-21T23:16:39Z</updated>
<author>
<name>Dirk Brandewie</name>
<email>dirk.j.brandewie@intel.com</email>
</author>
<published>2013-10-21T16:20:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7244cb62d96e735847dc9d08f870550df896898c'/>
<id>urn:sha1:7244cb62d96e735847dc9d08f870550df896898c</id>
<content type='text'>
The minimum pstate is supposed to be a percentage of the maximum P
state available.  Calculate min using max pstate and not the
current max which may have been limited by the user

Signed-off-by: Dirk Brandewie &lt;dirk.j.brandewie@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>intel_pstate: Improve accuracy by not truncating until final result</title>
<updated>2013-10-21T23:15:38Z</updated>
<author>
<name>Brennan Shacklett</name>
<email>brennan@genyes.org</email>
</author>
<published>2013-10-21T16:20:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d253d2a52676cfa3d89b8f0737a08ce7db665207'/>
<id>urn:sha1:d253d2a52676cfa3d89b8f0737a08ce7db665207</id>
<content type='text'>
This patch addresses Bug 60727
(https://bugzilla.kernel.org/show_bug.cgi?id=60727)
which was due to the truncation of intermediate values in the
calculations, which causes the code to consistently underestimate the
current cpu frequency, specifically 100% cpu utilization was truncated
down to the setpoint of 97%. This patch fixes the problem by keeping
the results of all intermediate calculations as fixed point numbers
rather scaling them back and forth between integers and fixed point.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60727
Signed-off-by: Brennan Shacklett &lt;bpshacklett@gmail.com&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>
</entry>
<entry>
<title>cpufreq: s3c64xx: Rename index to driver_data</title>
<updated>2013-10-16T21:53:38Z</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.wolfsonmicro.com</email>
</author>
<published>2013-10-14T18:36:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0e8244322b7fc45fd11a1c45f70b6bacddf4986f'/>
<id>urn:sha1:0e8244322b7fc45fd11a1c45f70b6bacddf4986f</id>
<content type='text'>
The index field of cpufreq_frequency_table has been renamed to
driver_data by commit 5070158 (cpufreq: rename index as driver_data
in cpufreq_frequency_table).

This patch updates the s3c64xx driver to match.

Signed-off-by: Charles Keepax &lt;ckeepax@opensource.wolfsonmicro.com&gt;
Cc: 3.11+ &lt;stable@vger.kernel.org&gt; # 3.11+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>intel_pstate: Fix type mismatch warning</title>
<updated>2013-10-16T20:59:33Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-10-16T20:59:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=09c87e2f79eb336bd313090be8113ae29345b8f5'/>
<id>urn:sha1:09c87e2f79eb336bd313090be8113ae29345b8f5</id>
<content type='text'>
The expression in line 398 of intel_pstate.c causes the following
warning to be emitted:

drivers/cpufreq/intel_pstate.c:398:3: warning: left shift count &gt;= width of type

which happens because unsigned long is 32-bit on some architectures.

Fix that by using a helper u64 variable and simplify the code
slightly.

Tested-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>cpufreq / intel_pstate: Fix max_perf_pct on resume</title>
<updated>2013-10-15T23:41:46Z</updated>
<author>
<name>Dirk Brandewie</name>
<email>dirk.j.brandewie@intel.com</email>
</author>
<published>2013-10-15T18:06:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=52e0a509e5d6f902ec26bc2a8bb02b137dc453be'/>
<id>urn:sha1:52e0a509e5d6f902ec26bc2a8bb02b137dc453be</id>
<content type='text'>
If the system is suspended while max_perf_pct is less than 100 percent
or no_turbo set policy-&gt;{min,max} will be set incorrectly with scaled
values which turn the scaled values into hard limits.

References: https://bugzilla.kernel.org/show_bug.cgi?id=61241
Reported-by: Patrick Bartels &lt;petzicus@googlemail.com&gt;
Signed-off-by: Dirk Brandewie &lt;dirk.j.brandewie@intel.com&gt;
Cc: 3.9+ &lt;stable@vger.kernel.org&gt; # 3.9+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
</feed>
