Skip to content
Snippets Groups Projects
  1. Mar 16, 2011
  2. Jan 13, 2010
    • Naga Chumbalkar's avatar
      [CPUFREQ] Processor Clocking Control interface driver · 0f1d683f
      Naga Chumbalkar authored
      
      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: default avatarNaga Chumbalkar <nagananda.chumbalkar@hp.com>
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      0f1d683f
    • Mike Frysinger's avatar
      292e0041
  3. Nov 24, 2009
    • Thomas Renninger's avatar
      [ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface · e2f74f35
      Thomas Renninger authored
      
      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 <venkatesh.pallipadi@intel.com>
      CC: Len Brown <lenb@kernel.org>
      CC: davej@codemonkey.org.uk
      CC: linux@dominikbrodowski.net
      
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      e2f74f35
    • Mark Brown's avatar
      [CPUFREQ] Document units for transition latency · bbe237aa
      Mark Brown authored
      
      They're documented in the header but not in Documentation.
      
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      bbe237aa
  4. Sep 01, 2009
    • Naga Chumbalkar's avatar
      [CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freq · da470db1
      Naga Chumbalkar authored
      
      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: default avatarNaga Chumbalkar <nagananda.chumbalkar@hp.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      da470db1
  5. Jun 15, 2009
  6. Feb 24, 2009
  7. Feb 03, 2009
  8. Dec 22, 2008
  9. Nov 25, 2008
  10. Oct 09, 2008
  11. Jul 26, 2008
  12. May 20, 2008
  13. Apr 28, 2008
  14. Jan 26, 2008
  15. May 09, 2007
  16. Nov 29, 2006
  17. Oct 15, 2006
  18. Oct 03, 2006
  19. Jul 31, 2006
    • Mattia Dongili's avatar
      [CPUFREQ] return error when failing to set minfreq · 9c9a43ed
      Mattia Dongili authored
      
      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: default avatarMattia Dongili <malattia@linux.it>
      Signed-off-by: Dominik Brodowski <linux at dominikbrodowski.net>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      
      --
      9c9a43ed
  20. Apr 03, 2006
  21. Dec 01, 2005
  22. Sep 10, 2005
  23. Jun 25, 2005
  24. May 31, 2005
  25. Apr 16, 2005
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!
Loading