linux-toradex.git/include/linux/cpufreq.h, branch imx-android-r13.3

ENGR00176177-2 Add irq count mechanism to interactive governor

2012-03-26T02:25:36+00:00

Add irq count to CPUFreq as a freq change condition.
Because some devices' working mode is unable to issue
CPUFreq change because of low CPU loading, but the cpu
freq will impact these devices' performace significantly.

Interactive govervor will sample the cpu loading as well
as the irq count which is registered. If the
loading or the irq count exceed the threshold we set,
governor will issue an CPUFreq change request.

These devices' irq threshold and enable/disable can be modified
via /sys/devices/system/cpu/cpufreq/interactive/irq_scaling

echo 0xAABBBC to change the default setting as below
AA : irq number
BBB: threshold
C  :enable or disable

Currently only enable USDHC3, USDHC4, GPU, SATA and
USB by default, we can add device to the init struct which is
located in arch/arm/mach-mx6/irq.c.

Signed-off-by: Anson Huang

ENGR00177745-1 Add interactive cpufreq governor

2012-03-26T02:25:36+00:00

cpufreq: interactive: New 'interactive' governor

This governor is designed for latency-sensitive workloads, such as
interactive user interfaces.  The interactive governor aims to be
significantly more responsive to ramp CPU quickly up when CPU-intensive
activity begins.

Existing governors sample CPU load at a particular rate, typically
every X ms.  This can lead to under-powering UI threads for the period of
time during which the user begins interacting with a previously-idle system
until the next sample period happens.

The 'interactive' governor uses a different approach. Instead of sampling
the CPU at a specified rate, the governor will check whether to scale the
CPU frequency up soon after coming out of idle.  When the CPU comes out of
idle, a timer is configured to fire within 1-2 ticks.  If the CPU is very
busy from exiting idle to when the timer fires then we assume the CPU is
underpowered and ramp to MAX speed.

If the CPU was not sufficiently busy to immediately ramp to MAX speed, then
the governor evaluates the CPU load since the last speed adjustment,
choosing the highest value between that longer-term load or the short-term
load since idle exit to determine the CPU speed to ramp to.

A realtime thread is used for scaling up, giving the remaining tasks the
CPU performance benefit, unlike existing governors which are more likely to
schedule rampup work to occur after your performance starved tasks have
completed.

The tuneables for this governor are:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_time:
    The minimum amount of time to spend at the current frequency before
    ramping down. This is to ensure that the governor has seen enough
    historic CPU load data to determine the appropriate workload.
/sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load
    The CPU load at which to ramp to max speed.

Signed-off-by: Anson Huang

[CPUFREQ] cpufreq.h: Fix some checkpatch.pl coding style issues.

2011-05-04T15:50:57+00:00

Before:
$ scripts/checkpatch.pl --file --terse include/linux/cpufreq.h
total: 14 errors, 11 warnings, 419 lines checked

After:
$ scripts/checkpatch.pl --file --terse include/linux/cpufreq.h
total: 2 errors, 4 warnings, 422 lines checked

Signed-off-by: Thiago Farina 
Signed-off-by: Dave Jones

[CPUFREQ] use dynamic debug instead of custom infrastructure

2011-05-04T15:50:57+00:00

With dynamic debug having gained the capability to report debug messages
also during the boot process, it offers a far superior interface for
debug messages than the custom cpufreq infrastructure. As a first step,
remove the old cpufreq_debug_printk() function and replace it with a call
to the generic pr_debug() function.

How can dynamic debug be used on cpufreq? You need a kernel which has
CONFIG_DYNAMIC_DEBUG enabled.

To enabled debugging during runtime, mount debugfs and

$ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control

for debugging the complete "cpufreq" module. To achieve the same goal during
boot, append

	ddebug_query="module cpufreq +p"

as a boot parameter to the kernel of your choice.

For more detailled instructions, please see
Documentation/dynamic-debug-howto.txt

Signed-off-by: Dominik Brodowski 
Signed-off-by: Dave Jones

[CPUFREQ] Remove the pm_message_t argument from driver suspend

2011-03-16T21:54:33+00:00

None of the existing cpufreq drivers uses the second argument of
its .suspend() callback (which isn't useful anyway), so remove it.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Dave Jones

[CPUFREQ] Remove old, deprecated per cpu ondemand/conservative sysfs files

2011-03-16T21:54:32+00:00

Marked deprecated for quite a whilte now...

Signed-off-by: Thomas Renninger 
Signed-off-by: Dave Jones 
CC: cpufreq@vger.kernel.org

[CPUFREQ] unexport (un)lock_policy_rwsem* functions

2010-08-03T17:47:04+00:00

lock_policy_rwsem_* and unlock_policy_rwsem_* functions are scheduled
to be unexported when 2.6.33. Now there are no other callers of them
out of cpufreq.c, unexport them and make them static.

Signed-off-by: WANG Cong 
Cc: Venkatesh Pallipadi 
Signed-off-by: Dave Jones

cpufreq: Unify sysfs attribute definition macros

2010-04-09T21:07:56+00:00

Multiple modules used to define those which are with identical
functionality and were needlessly replicated among the different cpufreq
drivers. Push them into the header and remove duplication.

Signed-off-by: Borislav Petkov 
LKML-Reference: <1270065406-1814-7-git-send-email-bp@amd64.org>
Reviewed-by: Thomas Renninger 
Signed-off-by: H. Peter Anvin

[ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface

2009-11-24T18:33:34+00:00

This interface is mainly intended (and implemented) for ACPI _PPC BIOS
frequency limitations, but other cpufreq drivers can also use it for
similar use-cases.

Why is this needed:

Currently it's not obvious why cpufreq got limited.
People see cpufreq/scaling_max_freq reduced, but this could have
happened by:
  - any userspace prog writing to scaling_max_freq
  - thermal limitations
  - hardware (_PPC in ACPI case) limitiations

Therefore export bios_limit (in kHz) to:
  - Point the user that it's the BIOS (broken or intended) which limits
    frequency
  - Export it as a sysfs interface for userspace progs.
    While this was a rarely used feature on laptops, there will appear
    more and more server implemenations providing "Green IT" features like
    allowing the service processor to limit the frequency. People want
    to know about HW/BIOS frequency limitations.

All ACPI P-state driven cpufreq drivers are covered with this patch:
  - powernow-k8
  - powernow-k7
  - acpi-cpufreq

Tested with a patched DSDT which limits the first two cores (_PPC returns 1)
via _PPC, exposed by bios_limit:
# echo 2200000 >cpu2/cpufreq/scaling_max_freq
# cat cpu*/cpufreq/scaling_max_freq
2600000
2600000
2200000
2200000
# #scaling_max_freq shows general user/thermal/BIOS limitations

# cat cpu*/cpufreq/bios_limit
2600000
2600000
2800000
2800000
# #bios_limit only shows the HW/BIOS limitation

CC: Pallipadi Venkatesh 
CC: Len Brown 
CC: davej@codemonkey.org.uk
CC: linux@dominikbrodowski.net

Signed-off-by: Thomas Renninger 
Signed-off-by: Dave Jones

cpufreq: add cpufreq_get() stub for CONFIG_CPU_FREQ=n

2009-10-29T14:39:24+00:00

When CONFIG_CPU_FREQ is disabled, cpufreq_get() needs a stub.  Used by kvm
(although it looks like a bit of the kvm code could be omitted when
CONFIG_CPU_FREQ is disabled).

arch/x86/built-in.o: In function `kvm_arch_init':
(.text+0x10de7): undefined reference to `cpufreq_get'

(Needed in linux-next's KVM tree, but it's correct in 2.6.32).

Signed-off-by: Randy Dunlap 
Tested-by: Eric Paris 
Cc: Jiri Slaby 
Cc: Avi Kivity 
Cc: Marcelo Tosatti 
Cc: Dave Jones 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds