linux-stable.git/Documentation/cpu-freq, branch linux-3.18.y

intel_pstate: Update documentation of {max,min}_perf_pct sysfs files

2014-07-06T23:22:19+00:00

Update documentation to make the interpretation of the values clearer

Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251
Cc: 3.13+   # 3.13+
Signed-off-by: Dirk Brandewie 
Signed-off-by: Rafael J. Wysocki

cpufreq: add support for intermediate (stable) frequencies

2014-06-05T21:32:29+00:00

Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.

While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize.

For example: When we transition between very low frequencies on exynos, like
between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
No CPUFREQ notification is sent for that. That means there's a period of time
when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
and 300MHz. And so udelay behaves badly.

To get this fixed in a generic way, introduce another set of callbacks
get_intermediate() and target_intermediate(), only for drivers with
target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.

get_intermediate() should return a stable intermediate frequency platform wants
to switch to, and target_intermediate() should set CPU to that frequency,
before jumping to the frequency corresponding to 'index'. Core will take care of
sending notifications and driver doesn't have to handle them in
target_intermediate() or target_index().

NOTE: ->target_index() should restore to policy->restore_freq in case of
failures as core would send notifications for that.

Tested-by: Stephen Warren 
Signed-off-by: Viresh Kumar 
Reviewed-by: Doug Anderson 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Move cpufreq specific OPP functions out of generic OPP library

2014-05-06T22:39:03+00:00

CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.

Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.

Cc: Kevin Hilman 
Signed-off-by: Nishanth Menon 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Make linux-pm@vger.kernel.org official mailing list

2014-04-30T23:15:32+00:00

There has been confusion all the time about which mailing list to follow
for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org.

Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork
which is a maintenance workflow problem, make linux-pm@vger.kernel.org
the official mailing list for cpufreq stuff and remove all references
of cpufreq@vger.kernel.org from kernel source.

Later, we can request that the list be dropped entirely.

Signed-off-by: Viresh Kumar 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

cpufreq: Introduce macros for cpufreq_frequency_table iteration

2014-04-29T22:05:31+00:00

Many cpufreq drivers need to iterate over the cpufreq_frequency_table
for various tasks.

This patch introduces two macros which can be used for iteration over
cpufreq_frequency_table keeping a common coding style across drivers:

- cpufreq_for_each_entry: iterate over each entry of the table
- cpufreq_for_each_valid_entry: iterate over each entry that contains
a valid frequency.

It should have no functional changes.

Signed-off-by: Stratos Karafotis 
Acked-by: Lad, Prabhakar 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Add stop CPU callback to cpufreq_driver interface

2014-03-20T02:50:12+00:00

This callback allows the driver to do clean up before the CPU is
completely down and its state cannot be modified.  This is used
by the intel_pstate driver to reduce the requested P state prior to
the core going away.  This is required because the requested P state
of the offline core is used to select the package P state. This
effectively sets the floor package P state to the requested P state on
the offline core.

Signed-off-by: Dirk Brandewie 
[rjw: Minor modifications]
Signed-off-by: Rafael J. Wysocki

cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}

2014-03-19T13:10:24+00:00

Two cpufreq notifiers CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE have
not been used for some time, so remove them to clean up code a bit.

Signed-off-by: Viresh Kumar 
Reviewed-by: Srivatsa S. Bhat 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

Documentation: cpufreq / boost: Update BOOST documentation

2014-01-17T01:00:45+00:00

Since the support for software and hardware controlled boosting has
been added, update the corresponding documentation.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Myungjoo Ham 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

Documentation / cpufreq: add intel-pstate.txt

2014-01-06T00:14:25+00:00

The Intel P-state driver is currently undocumented. Add some
documentation based on the cover-letter sent with the original series.

Cc: Dirk Brandewie 
Acked-by: Randy Dunlap 
Signed-off-by: Ramkumar Ramachandra 
Signed-off-by: Rafael J. Wysocki

cpufreq: Implement light weight ->target_index() routine

2013-10-25T20:42:24+00:00

Currently, the prototype of cpufreq_drivers target routines is:

int target(struct cpufreq_policy *policy, unsigned int target_freq,
		unsigned int relation);

And most of the drivers call cpufreq_frequency_table_target() to get a valid
index of their frequency table which is closest to the target_freq. And they
don't use target_freq and relation after that.

So, it makes sense to just do this work in cpufreq core before calling
cpufreq_frequency_table_target() and simply pass index instead. But this can be
done only with drivers which expose their frequency table with cpufreq core. For
others we need to stick with the old prototype of target() until those drivers
are converted to expose frequency tables.

This patch implements the new light weight prototype for target_index() routine.
It looks like this:

int target_index(struct cpufreq_policy *policy, unsigned int index);

CPUFreq core will call cpufreq_frequency_table_target() before calling this
routine and pass index to it. Because CPUFreq core now requires to call routines
present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.

This also marks target() interface as deprecated. So, that new drivers avoid
using it. And Documentation is updated accordingly.

It also converts existing .target() to newly defined light weight
.target_index() routine for many driver.

Acked-by: Hans-Christian Egtvedt 
Acked-by: Jesper Nilsson 
Acked-by: Linus Walleij 
Acked-by: Russell King 
Acked-by: David S. Miller 
Tested-by: Andrew Lunn 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki