linux-toradex.git/Documentation/cpu-freq/user-guide.txt, branch v3.4.22

[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] update Doc for cpuinfo_cur_freq and scaling_cur_freq

2009-09-01T16:45:09+00:00

I think the way "cpuinfo_cur_info" and "scaling_cur_info" are defined under
./Documentation/cpu-freq/user-guide.txt can be enhanced. Currently, they are
both defined the same way: "Current speed/frequency" of the CPU, in KHz".

Below is a patch that distinguishes one from the other.

Regards,
- naga -

-----------------------------------------
Update description for "cpuinfo_cur_freq" and "scaling_cur_freq".

Some of the wording is drawn from comments found in
./drivers/cpufreq/cpufreq.c: cpufreq_out_of_sync():

 *      @old_freq: CPU frequency the kernel thinks the CPU runs at
 *      @new_freq: CPU frequency the CPU actually runs at

Signed-off-by: Naga Chumbalkar 
Signed-off-by: Dave Jones

[CPUFREQ] minor correction to cpu-freq documentation

2009-06-15T15:49:42+00:00

I have been reading the documentation for cpufreq closely. Found a couple of
minor errors in the Documentation.

Signed-off-by: Naga Chumbalkar 
Signed-off-by: Dave Jones

[CPUFREQ] Introduce /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency

2009-02-25T03:47:31+00:00

It's not only useful for the ondemand and conservative governors, but
also for userspace daemons to know about the HW transition latency of
the CPU.
It is especially useful for userspace to know about this value when
the ondemand or conservative governors are run. The sampling rate
control value depends on it and for userspace being able to set sane
tuning values there it has to know about the transition latency.

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

ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc entries

2009-02-04T05:12:24+00:00

They were long enough set deprecated...

Update Documentation/cpu-freq/users-guide.txt:
The deprecated files listed there seen not to exist for some time anymore
already.

Signed-off-by: Thomas Renninger 
Signed-off-by: Len Brown

doc: Update sh cpufreq documentation.

2008-12-22T09:44:47+00:00

The sh cpufreq driver is no longer limited to just the SH-3 and SH-4,
update the documentation to reflect this fact accordingly.

Signed-off-by: Paul Mundt

[CPUFREQ] Documentation: Add Blackfin to list of supported processors

2008-11-25T18:38:29+00:00

Signed-off-by: Robin Getz 
Signed-off-by: Bryan Wu 
Signed-off-by: Dave Jones

[CPUFREQ] document the currently undocumented parts of the sysfs interface

2008-04-28T20:27:08+00:00

There is a description of some of the sysfs files.  However, there are some
that are not mentioned in the documentation, so add them to the user's guide.

Signed-off-by: Darrick J. Wong 
Cc: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Jones

[ARM] pxa: add cpufreq support

2008-01-26T15:07:52+00:00

There have been patches hanging around for ages to add support for
cpufreq to PXA255 processors.  It's about time we applied one.

Signed-off-by: Russell King

[CPUFREQ] return error when failing to set minfreq

2006-07-31T22:37:05+00:00

I just stumbled on this bug/feature, this is how to reproduce it:

# echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
# echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# cpufreq-info -p
450000 450000 powersave
# echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq ; echo $?
0
# cpufreq-info -p
450000 450000 powersave

Here it is. The kernel refuses to set a min_freq higher than the
max_freq but it allows a max_freq lower than min_freq (lowering min_freq
also).

This behaviour is pretty straightforward (but undocumented) and it
doesn't return an error altough failing to accomplish the requested
action (set min_freq).
The problem (IMO) is basically that userspace is not allowed to set a
full policy atomically while the kernel always does that thus it must
enforce an ordering on operations.

The attached patch returns -EINVAL if trying to increase frequencies
starting from scaling_min_freq and documents the correct ordering of writes.

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

--