1. 26 7月, 2013 1 次提交
  2. 04 7月, 2013 1 次提交
    • V
      cpufreq: Fix serialization of frequency transitions · 266c13d7
      Viresh Kumar 提交于
      Commit 7c30ed ("cpufreq: make sure frequency transitions are serialized")
      interacts poorly with systems that have a single core freqency for all
      cores.  On such systems we have a single policy for all cores with
      several CPUs.  When we do a frequency transition the governor calls the
      pre and post change notifiers which causes cpufreq_notify_transition()
      per CPU.  Since the policy is the same for all of them all CPUs after
      the first and the warnings added are generated by checking a per-policy
      flag the warnings will be triggered for all cores after the first.
      
      Fix this by allowing notifier to be called for n times. Where n is the number of
      cpus in policy->cpus.
      Reported-and-tested-by: NMark Brown <broonie@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      266c13d7
  3. 28 6月, 2013 2 次提交
  4. 21 6月, 2013 2 次提交
    • V
      cpufreq: Fix minor formatting issues · bb176f7d
      Viresh Kumar 提交于
      There were a few noticeable formatting issues in core cpufreq code.
      This cleans them up to make code look better.  The changes include:
       - Whitespace cleanup.
       - Rearrangements of code.
       - Multiline comments fixes.
       - Formatting changes to fit 80 columns.
      
      Copyright information in cpufreq.c is also updated to include my name
      for 2013.
      
      [rjw: Changelog]
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bb176f7d
    • X
      cpufreq: Fix governor start/stop race condition · 95731ebb
      Xiaoguang Chen 提交于
      Cpufreq governors' stop and start operations should be carried out
      in sequence.  Otherwise, there will be unexpected behavior, like in
      the example below.
      
      Suppose there are 4 CPUs and policy->cpu=CPU0, CPU1/2/3 are linked
      to CPU0.  The normal sequence is:
      
       1) Current governor is userspace.  An application tries to set the
          governor to ondemand.  It will call __cpufreq_set_policy() in
          which it will stop the userspace governor and then start the
          ondemand governor.
      
       2) Current governor is userspace.  The online of CPU3 runs on CPU0.
          It will call cpufreq_add_policy_cpu() in which it will first
          stop the userspace governor, and then start it again.
      
      If the sequence of the above two cases interleaves, it becomes:
      
       1) Application stops userspace governor
       2)                                  Hotplug stops userspace governor
      
      which is a problem, because the governor shouldn't be stopped twice
      in a row.  What happens next is:
      
       3) Application starts ondemand governor
       4)                                  Hotplug starts a governor
      
      In step 4, the hotplug is supposed to start the userspace governor,
      but now the governor has been changed by the application to ondemand,
      so the ondemand governor is started once again, which is incorrect.
      
      The solution is to prevent policy governors from being stopped
      multiple times in a row.  A governor should only be stopped once for
      one policy.  After it has been stopped, no more governor stop
      operations should be executed.
      
      Also add a mutex to serialize governor operations.
      
      [rjw: Changelog.  And you owe me a beverage of my choice.]
      Signed-off-by: NXiaoguang Chen <chenxg@marvell.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      95731ebb
  5. 04 6月, 2013 1 次提交
  6. 27 5月, 2013 3 次提交
  7. 02 4月, 2013 1 次提交
  8. 01 4月, 2013 2 次提交
    • V
      cpufreq: governor: Implement per policy instances of governors · 4d5dcc42
      Viresh Kumar 提交于
      Currently, there can't be multiple instances of single governor_type.
      If we have a multi-package system, where we have multiple instances
      of struct policy (per package), we can't have multiple instances of
      same governor. i.e. We can't have multiple instances of ondemand
      governor for multiple packages.
      
      Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/
      governor-name/. Which again reflects that there can be only one
      instance of a governor_type in the system.
      
      This is a bottleneck for multicluster system, where we want different
      packages to use same governor type, but with different tunables.
      
      This patch uses the infrastructure provided by earlier patch and
      implements init/exit routines for ondemand and conservative
      governors.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4d5dcc42
    • V
      cpufreq: Add per policy governor-init/exit infrastructure · 7bd353a9
      Viresh Kumar 提交于
      Currently, there can't be multiple instances of single governor_type.
      If we have a multi-package system, where we have multiple instances
      of struct policy (per package), we can't have multiple instances of
      same governor. i.e. We can't have multiple instances of ondemand
      governor for multiple packages.
      
      Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/
      governor-name/. Which again reflects that there can be only one
      instance of a governor_type in the system.
      
      This is a bottleneck for multicluster system, where we want different
      packages to use same governor type, but with different tunables.
      
      This patch is inclined towards providing this infrastructure. Because
      we are required to allocate governor's resources dynamically now, we
      must do it at policy creation and end. And so got
      CPUFREQ_GOV_POLICY_INIT/EXIT.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7bd353a9
  9. 02 2月, 2013 7 次提交
  10. 15 11月, 2012 3 次提交
  11. 21 3月, 2012 1 次提交
  12. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  13. 15 3月, 2012 1 次提交
  14. 29 6月, 2011 1 次提交
  15. 04 5月, 2011 2 次提交
    • T
      [CPUFREQ] cpufreq.h: Fix some checkpatch.pl coding style issues. · 335dc333
      Thiago Farina 提交于
      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: NThiago Farina <tfransosi@gmail.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      335dc333
    • D
      [CPUFREQ] use dynamic debug instead of custom infrastructure · 2d06d8c4
      Dominik Brodowski 提交于
      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: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      2d06d8c4
  16. 17 3月, 2011 2 次提交
  17. 04 8月, 2010 1 次提交
  18. 10 4月, 2010 1 次提交
  19. 25 11月, 2009 1 次提交
    • 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
  20. 29 10月, 2009 1 次提交
  21. 02 9月, 2009 1 次提交
  22. 10 3月, 2009 1 次提交
    • D
      Revert "[CPUFREQ] Disable sysfs ui for p4-clockmod." · 129f8ae9
      Dave Jones 提交于
      This reverts commit e088e4c9.
      
      Removing the sysfs interface for p4-clockmod was flagged as a
      regression in bug 12826.
      
      Course of action:
       - Find out the remaining causes of overheating, and fix them
         if possible. ACPI should be doing the right thing automatically.
         If it isn't, we need to fix that.
       - mark p4-clockmod ui as deprecated
       - try again with the removal in six months.
      
      It's not really feasible to printk about the deprecation, because
      it needs to happen at all the sysfs entry points, which means adding
      a lot of strcmp("p4-clockmod".. calls to the core, which.. bleuch.
      Signed-off-by: NDave Jones <davej@redhat.com>
      129f8ae9
  23. 06 1月, 2009 1 次提交
  24. 06 12月, 2008 1 次提交
    • M
      [CPUFREQ] Disable sysfs ui for p4-clockmod. · e088e4c9
      Matthew Garrett 提交于
      p4-clockmod has a long history of abuse.   It pretends to be a CPU
      frequency scaling driver, even though it doesn't actually change
      the CPU frequency, but instead just modulates the frequency with
      wait-states.
      The biggest misconception is that when running at the lower 'frequency'
      p4-clockmod is saving power.  This isn't the case, as workloads running
      slower take longer to complete, preventing the CPU from entering deep C states.
      
      However p4-clockmod does have a purpose.  It can prevent overheating.
      Having it hooked up to the cpufreq interfaces is the wrong way to achieve
      cooling however. It should instead be hooked up to ACPI.
      
      This diff introduces a means for a cpufreq driver to register with the
      cpufreq core, but not present a sysfs interface.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      e088e4c9
  25. 10 10月, 2008 1 次提交