1. 10 8月, 2013 1 次提交
  2. 04 6月, 2013 1 次提交
  3. 10 4月, 2013 1 次提交
  4. 03 4月, 2013 1 次提交
    • F
      nohz: Rename CONFIG_NO_HZ to CONFIG_NO_HZ_COMMON · 3451d024
      Frederic Weisbecker 提交于
      We are planning to convert the dynticks Kconfig options layout
      into a choice menu. The user must be able to easily pick
      any of the following implementations: constant periodic tick,
      idle dynticks, full dynticks.
      
      As this implies a mutual exclusion, the two dynticks implementions
      need to converge on the selection of a common Kconfig option in order
      to ease the sharing of a common infrastructure.
      
      It would thus seem pretty natural to reuse CONFIG_NO_HZ to
      that end. It already implements all the idle dynticks code
      and the full dynticks depends on all that code for now.
      So ideally the choice menu would propose CONFIG_NO_HZ_IDLE and
      CONFIG_NO_HZ_EXTENDED then both would select CONFIG_NO_HZ.
      
      On the other hand we want to stay backward compatible: if
      CONFIG_NO_HZ is set in an older config file, we want to
      enable CONFIG_NO_HZ_IDLE by default.
      
      But we can't afford both at the same time or we run into
      a circular dependency:
      
      1) CONFIG_NO_HZ_IDLE and CONFIG_NO_HZ_EXTENDED both select
         CONFIG_NO_HZ
      2) If CONFIG_NO_HZ is set, we default to CONFIG_NO_HZ_IDLE
      
      We might be able to support that from Kconfig/Kbuild but it
      may not be wise to introduce such a confusing behaviour.
      
      So to solve this, create a new CONFIG_NO_HZ_COMMON option
      which gathers the common code between idle and full dynticks
      (that common code for now is simply the idle dynticks code)
      and select it from their referring Kconfig.
      
      Then we'll later create CONFIG_NO_HZ_IDLE and map CONFIG_NO_HZ
      to it for backward compatibility.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Gilad Ben Yossef <gilad@benyossef.com>
      Cc: Hakan Akkan <hakanakkan@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      3451d024
  5. 02 4月, 2013 2 次提交
  6. 01 4月, 2013 1 次提交
  7. 02 2月, 2013 1 次提交
  8. 10 9月, 2012 1 次提交
    • A
      acpi-cpufreq: Add support for disabling dynamic overclocking · 615b7300
      Andre Przywara 提交于
      One feature present in powernow-k8 that isn't present in acpi-cpufreq
      is support for enabling or disabling AMD's core performance boost
      technology. This patch adds support to acpi-cpufreq, but also
      includes support for Intel's dynamic acceleration.
      
      The original boost disabling sysfs file was per CPU, but acted
      globally. Also the naming (cpb) was at least not intuitive.
      So lets introduce a single file simply called "boost", which sits
      once in /sys/devices/system/cpu/cpufreq.
      This should be the only way of using this feature, so add
      documentation about the rationale and the usage.
      
      A following patch will re-introduce the cpb knob for compatibility
      reasons on AMD CPUs.
      
      Per-CPU boost switching is possible, but not trivial and is thus
      postponed to a later patch series.
      Signed-off-by: NAndre Przywara <andre.przywara@amd.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      615b7300
  9. 08 11月, 2011 1 次提交
  10. 09 8月, 2011 1 次提交
  11. 13 6月, 2011 1 次提交
  12. 17 3月, 2011 1 次提交
  13. 13 1月, 2010 2 次提交
    • N
      [CPUFREQ] Processor Clocking Control interface driver · 0f1d683f
      Naga Chumbalkar 提交于
      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: NNaga Chumbalkar <nagananda.chumbalkar@hp.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      0f1d683f
    • M
      [CPUFREQ] fix default value for ondemand governor · 292e0041
      Mike Frysinger 提交于
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      292e0041
  14. 25 11月, 2009 2 次提交
    • T
      [ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface · e2f74f35
      Thomas Renninger 提交于
      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: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      e2f74f35
    • M
      [CPUFREQ] Document units for transition latency · bbe237aa
      Mark Brown 提交于
      They're documented in the header but not in Documentation.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      bbe237aa
  15. 02 9月, 2009 1 次提交
    • N
      [CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freq · da470db1
      Naga Chumbalkar 提交于
      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: NNaga Chumbalkar <nagananda.chumbalkar@hp.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      da470db1
  16. 15 6月, 2009 2 次提交
  17. 25 2月, 2009 3 次提交
  18. 04 2月, 2009 1 次提交
  19. 22 12月, 2008 1 次提交
  20. 26 11月, 2008 1 次提交
  21. 10 10月, 2008 1 次提交
  22. 27 7月, 2008 1 次提交
  23. 21 5月, 2008 1 次提交
  24. 29 4月, 2008 1 次提交
  25. 26 1月, 2008 1 次提交
  26. 09 5月, 2007 1 次提交
  27. 30 11月, 2006 1 次提交
  28. 16 10月, 2006 1 次提交
  29. 04 10月, 2006 4 次提交
  30. 01 8月, 2006 1 次提交
    • M
      [CPUFREQ] return error when failing to set minfreq · 9c9a43ed
      Mattia Dongili 提交于
      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: NMattia Dongili <malattia@linux.it>
      Signed-off-by: Dominik Brodowski <linux at dominikbrodowski.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      
      --
      9c9a43ed
  31. 03 4月, 2006 1 次提交