08 Nov, 2011

1 commit

  • 'sampling_rate_max' was removed with commit ef598549 ("[...] Remove
    deprecated sysfs file sampling_rate_max"), so its line can be dropped
    from governors.txt. And 'show_sampling_rate_min' is a typo: the sysfs
    file is called 'sampling_rate_min'.

    Signed-off-by: Paul Bolle
    Signed-off-by: Jiri Kosina

    Paul Bolle
     

09 Aug, 2011

1 commit


13 Jun, 2011

1 commit

  • Change all "arch/i386" to "arch/x86" in Documentaion/,
    since the directory has changed.

    Also update the files which have changed their filename
    in the meantime accordingly.

    Signed-off-by: Wanlong Gao
    [jkosina@suse.cz: reword changelog]
    Signed-off-by: Jiri Kosina

    Wanlong Gao
     

17 Mar, 2011

1 commit


13 Jan, 2010

2 commits

  • Processor Clocking Control (PCC) is an interface between the BIOS and OSPM.
    Based on the server workload, OSPM can request what frequency it expects
    from a logical CPU, and the BIOS will achieve that frequency transparently.

    This patch introduces driver support for PCC. OSPM uses the PCC driver to
    communicate with the BIOS via the PCC interface.

    There is a Documentation file that provides a link to the PCC
    Specification, and also provides a summary of the PCC interface.

    Currently, certain HP ProLiant platforms implement the PCC interface. However,
    any platform whose BIOS implements the PCC Specification, can utilize this
    driver.

    V2 --> V1 changes (based on Dominik's suggestions):
    - Removed the dependency on CPU_FREQ_TABLE
    - "cpufreq_stats" will no longer PANIC. Actually, it will not load anymore
    because it is not applicable.
    - Removed the sanity check for target frequency in the ->target routine.

    NOTE: A patch to sanitize the target frequency requested by "ondemand" is
    needed to ensure that the target freq < policy->min.

    Can this driver be queued up for the 2.6.33 tree?

    Signed-off-by: Naga Chumbalkar
    Signed-off-by: Matthew Garrett
    Signed-off-by: Thomas Renninger
    Signed-off-by: Dave Jones

    Naga Chumbalkar
     
  • Signed-off-by: Mike Frysinger
    Signed-off-by: Dave Jones

    Mike Frysinger
     

25 Nov, 2009

2 commits

  • 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

    Thomas Renninger
     
  • They're documented in the header but not in Documentation.

    Signed-off-by: Mark Brown
    Signed-off-by: Dave Jones

    Mark Brown
     

02 Sep, 2009

1 commit

  • 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

    Naga Chumbalkar
     

15 Jun, 2009

2 commits


25 Feb, 2009

3 commits


04 Feb, 2009

1 commit


22 Dec, 2008

1 commit


26 Nov, 2008

1 commit


10 Oct, 2008

1 commit


27 Jul, 2008

1 commit


21 May, 2008

1 commit


29 Apr, 2008

1 commit


26 Jan, 2008

1 commit


09 May, 2007

1 commit


13 Dec, 2006

1 commit


30 Nov, 2006

1 commit


16 Oct, 2006

1 commit


04 Oct, 2006

4 commits


01 Aug, 2006

1 commit

  • 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

    --

    Mattia Dongili
     

03 Apr, 2006

1 commit


01 Dec, 2005

1 commit


11 Sep, 2005

1 commit

  • The attached patch fixes the following spelling errors in Documentation/
    - double "the"
    - Several misspellings of function/functionality
    - infomation
    - memeory
    - Recieved
    - wether
    and possibly others which I forgot ;-)
    Trailing whitespaces on the same line as the typo are also deleted.

    Signed-off-by: Tobias Klauser
    Signed-off-by: Domen Puncer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tobias Klauser
     

26 Jun, 2005

1 commit

  • I corrected a small error and enhanced the govenor.txt file with the
    ondemand daemon because the kernel configs link to the documentation but
    ondemand wasn't documentated. Feel free to include the patch in the
    attachment.

    Cc: Dominik Brodowski
    Cc: Dave Jones
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nico Golde
     

01 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds