kernel.git/drivers/cpufreq/intel_pstate.c, branch linux-3.11.y

cpufreq / intel_pstate: Fix max_perf_pct on resume

2013-11-13T03:08:06Z

commit 52e0a509e5d6f902ec26bc2a8bb02b137dc453be upstream. If the system is suspended while max_perf_pct is less than 100 percent or no_turbo set policy->{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 Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq / intel_pstate: Change to scale off of max P-state

2013-07-23T02:18:28Z

Change to using max P-state instead of max turbo P-state. This change resolves two issues. On a quiet system intel_pstate can fail to respond to a load change. On CPU SKUs that have a limited number of P-states and no turbo range intel_pstate fails to select the highest available P-state. This change is suitable for stable v3.9+ References: https://bugzilla.kernel.org/show_bug.cgi?id=59481 Reported-and-tested-by: Arjan van de Ven Reported-and-tested-by: dsmythies@telus.net Signed-off-by: Dirk Brandewie Acked-by: Viresh Kumar Cc: 3.9+ Signed-off-by: Rafael J. Wysocki

cpufreq: delete __cpuinit usage from all cpufreq files

2013-07-14T23:36:57Z

The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/cpufreq uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 [v2: leave 2nd lines of args misaligned as requested by Viresh] Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: cpufreq@vger.kernel.org Cc: linux-pm@vger.kernel.org Acked-by: Dirk Brandewie Acked-by: Viresh Kumar Signed-off-by: Paul Gortmaker

cpufreq / intel_pstate: Add additional supported CPU ID

2013-05-21T22:28:44Z

Add CPU ID for Ivybrigde processor. Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

cpufreq / intel_pstate: use vzalloc() instead of vmalloc()/memset(0)

2013-05-13T23:39:28Z

Use vzalloc() instead of vmalloc() and memset(0). Signed-off-by: Wei Yongjun Acked-by: Viresh Kumar Acked-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

cpufreq / intel_pstate: remove #ifdef MODULE compile fence

2013-05-12T12:04:17Z

The driver can no longer be built as a module remove the compile fence around cpufreq tracing call. Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

cpufreq / intel_pstate: Remove idle mode PID

2013-05-12T12:04:17Z

Remove dead code from the driver. Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

cpufreq / intel_pstate: fix ffmpeg regression

2013-05-12T12:04:16Z

The ffmpeg benchmark in the phoronix test suite has threads on multiple cores that rely on the progress on of threads on other cores and ping pong back and forth fast enough to make the core appear less busy than it "should" be. If the core has been at minimum p-state for a while bump the pstate up to kick the core to see if it is in this ping pong state. If the core is truly idle the p-state will be reduced at the next sample time. If the core makes more progress it will send more work to the thread bringing both threads out of the ping pong scenario and the p-state will be selected normally. This fixes a performance regression of approximately 30% Cc: 3.9+ Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

cpufreq / intel_pstate: use lowest requested max performance

2013-05-12T12:04:16Z

There are two ways that the maximum p-state can be clamped, via a policy change and via the sysfs file. The acpi-thermal driver adjusts the p-state policy in response to thermal events. These changes override the users settings at the moment. Use the lowest of the two requested values this ensures that we will not exceed the requested pstate from either mechanism. Reported-by: Srinivas Pandruvada Cc: 3.9+ Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki

cpufreq / intel_pstate: remove idle time and duration from sample and calculations

2013-05-12T12:04:16Z

Idle time is taken into account in the APERF/MPERF ratio calculation there is no reason for the driver to track it seperately. This reduces the work in the driver and makes the code more readable. Removal of the tracking of sample duration removes the possibility of the divide by zero exception when the duration is sub 1us References: https://bugzilla.kernel.org/show_bug.cgi?id=56691 Reported-by: Mike Lothian Cc: 3.9+ Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki