1. 21 Sep, 2012 1 commit
    • Daniel Lezcano's avatar
      cpuidle: rename function name "__cpuidle_register_driver", v2 · ed953472
      Daniel Lezcano authored
      The function __cpuidle_register_driver name is confusing because it
      suggests, conforming to the coding style of the kernel, it registers
      the driver without taking a lock. Actually, it just fill the different
      power field states with a decresing value if the power has not been
      specified.
      
      Clarify the purpose of the function by changing its name and
      move the condition out of this function.
      
      This patch fix nothing and does not change the behavior of the
      function. It is just for the sake of clarity.
      
      IHMO, reading in the code:
      
      +       if (!drv->power_specified)
      +               set_power_states(drv);
      
      is much more explicit than:
      
      -       __cpuidle_register_driver(drv);
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      ed953472
  2. 19 Sep, 2012 1 commit
  3. 17 Sep, 2012 1 commit
    • Daniel Lezcano's avatar
      cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure · 3d339dcb
      Daniel Lezcano authored
      Currently we have the cpuidle_device field in the acpi_processor_power structure.
      This adds a dependency between processor.h and cpuidle.h
      
      Although it is not a real problem, removing this dependency has the benefit of
      separating a bit more the cpuidle code from the rest of the acpi code.
      Also, the compilation should be a bit improved because we do no longer
      include cpuidle.h in processor.h. The preprocessor was generating 30418 loc
      and with this patch it generates 30256 loc for processor_thermal.c, a file
      which is not concerned at all by cpuidle, like processor_perflib.c and
      processor_throttling.c.
      
      That may sound ridiculous, but "small streams make big rivers" :P
      
      This patch moves this field into a static global per cpu variable like what is
      done in the intel_idle driver.
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      3d339dcb
  4. 15 Sep, 2012 2 commits
  5. 05 Sep, 2012 1 commit
  6. 03 Sep, 2012 2 commits
    • Rafael J. Wysocki's avatar
      PM / cpuidle: Make ladder governor use the "disabled" state flag · 66804c13
      Rafael J. Wysocki authored
      For the mechanism introduced by commit cbc9ef02 (PM / Domains: Add
      preliminary support for cpuidle, v2) to work with the ladder
      governor, that governor should respect the "disabled" state flag
      added by that commit.  Change the ladder governor accordingly.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      66804c13
    • Carsten Emde's avatar
      Honor state disabling in the cpuidle ladder governor · 62d6ae88
      Carsten Emde authored
      There are two cpuidle governors ladder and menu. While the ladder
      governor is always available, if CONFIG_CPU_IDLE is selected, the
      menu governor additionally requires CONFIG_NO_HZ.
      
      A particular C state can be disabled by writing to the sysfs file
      /sys/devices/system/cpu/cpuN/cpuidle/stateN/disable, but this mechanism
      is only implemented in the menu governor. Thus, in a system where
      CONFIG_NO_HZ is not selected, the ladder governor becomes default and
      always will walk through all sleep states - irrespective of whether the
      C state was disabled via sysfs or not. The only way to select a specific
      C state was to write the related latency to /dev/cpu_dma_latency and
      keep the file open as long as this setting was required - not very
      practical and not suitable for setting a single core in an SMP system.
      
      With this patch, the ladder governor only will promote to the next
      C state, if it has not been disabled, and it will demote, if the
      current C state was disabled.
      
      Note that the patch does not make the setting of the sysfs variable
      "disable" coherent, i.e. if one is disabling a light state, then all
      deeper states are disabled as well, but the "disable" variable does not
      reflect it. Likewise, if one enables a deep state but a lighter state
      still is disabled, then this has no effect. A related section has been
      added to the documentation.
      Signed-off-by: default avatarCarsten Emde <C.Emde@osadl.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      62d6ae88
  7. 01 Sep, 2012 5 commits
  8. 30 Aug, 2012 5 commits
  9. 29 Aug, 2012 18 commits
  10. 28 Aug, 2012 4 commits