1. 31 Oct, 2011 1 commit
  2. 28 Feb, 2011 1 commit
  3. 17 Feb, 2011 2 commits
  4. 24 Jan, 2011 1 commit
  5. 12 Jan, 2011 5 commits
    • Thomas Renninger's avatar
      cpuidle/x86/perf: fix power:cpu_idle double end events and throw cpu_idle... · f77cfe4e
      Thomas Renninger authored
      cpuidle/x86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
      
      Currently intel_idle and acpi_idle driver show double cpu_idle "exit idle"
      events -> this patch fixes it and makes cpu_idle events throwing less complex.
      
      It also introduces cpu_idle events for all architectures which use
      the cpuidle subsystem, namely:
        - arch/arm/mach-at91/cpuidle.c
        - arch/arm/mach-davinci/cpuidle.c
        - arch/arm/mach-kirkwood/cpuidle.c
        - arch/arm/mach-omap2/cpuidle34xx.c
        - arch/drivers/acpi/processor_idle.c (for all cases, not only mwait)
        - arch/x86/kernel/process.c (did throw events before, but was a mess)
        - drivers/idle/intel_idle.c (did throw events before)
      
      Convention should be:
      Fire cpu_idle events inside the current pm_idle function (not somewhere
      down the the callee tree) to keep things easy.
      
      Current possible pm_idle functions in X86:
      c1e_idle, poll_idle, cpuidle_idle_call, mwait_idle, default_idle
      -> this is really easy is now.
      
      This affects userspace:
      The type field of the cpu_idle power event can now direclty get
      mapped to:
      /sys/devices/system/cpu/cpuX/cpuidle/stateX/{name,desc,usage,time,...}
      instead of throwing very CPU/mwait specific values.
      This change is not visible for the intel_idle driver.
      For the acpi_idle driver it should only be visible if the vendor
      misses out C-states in his BIOS.
      Another (perf timechart) patch reads out cpuidle info of cpu_idle
      events from:
      /sys/.../cpuidle/stateX/*, then the cpuidle events are mapped
      to the correct C-/cpuidle state again, even if e.g. vendors miss
      out C-states in their BIOS and for example only export C1 and C3.
      -> everything is fine.
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      CC: Robert Schoene <robert.schoene@tu-dresden.de>
      CC: Jean Pihet <j-pihet@ti.com>
      CC: Arjan van de Ven <arjan@linux.intel.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      CC: linux-pm@lists.linux-foundation.org
      CC: linux-acpi@vger.kernel.org
      CC: linux-kernel@vger.kernel.org
      CC: linux-perf-users@vger.kernel.org
      CC: linux-omap@vger.kernel.org
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      f77cfe4e
    • Shaohua Li's avatar
      intel_idle: open broadcast clock event · 2a2d31c8
      Shaohua Li authored
      Intel_idle driver uses CLOCK_EVT_NOTIFY_BROADCAST_ENTER
      CLOCK_EVT_NOTIFY_BROADCAST_EXIT
      for broadcast clock events. The _ENTER/_EXIT doesn't really open broadcast clock
      events, please see processor_idle.c for an example. In some situation, this will
      cause boot hang, because some CPUs enters idle but local APIC timer stalls.
      Reported-and-tested-by: default avatarYan Zheng <zheng.z.yan@intel.com>
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      cc: stable@kernel.org
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      2a2d31c8
    • Len Brown's avatar
      956d033f
    • Thomas Renninger's avatar
      ACPI, intel_idle: Cleanup idle= internal variables · d1896049
      Thomas Renninger authored
      Having four variables for the same thing:
        idle_halt, idle_nomwait, force_mwait and boot_option_idle_overrides
      is rather confusing and unnecessary complex.
      
      if idle= boot param is passed, only set up one variable:
      boot_option_idle_overrides
      
      Introduces following functional changes/fixes:
        - intel_idle driver does not register if any idle=xy
          boot param is passed.
        - processor_idle.c will also not register a cpuidle driver
          and get active if idle=halt is passed.
          Before a cpuidle driver with one (C1, halt) state got registered
          Now the default_idle function will be used which finally uses
          the same idle call to enter sleep state (safe_halt()), but
          without registering a whole cpuidle driver.
      
      That means idle= param will always avoid cpuidle drivers to register
      with one exception (same behavior as before):
      idle=nomwait
      may still register acpi_idle cpuidle driver, but C1 will not use
      mwait, but hlt. This can be a workaround for IO based deeper sleep
      states where C1 mwait causes problems.
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      cc: x86@kernel.org
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      d1896049
    • Len Brown's avatar
  6. 04 Jan, 2011 2 commits
  7. 01 Dec, 2010 1 commit
  8. 26 Oct, 2010 1 commit
  9. 23 Oct, 2010 1 commit
  10. 15 Oct, 2010 2 commits
  11. 08 Oct, 2010 1 commit
  12. 30 Sep, 2010 1 commit
  13. 28 Sep, 2010 2 commits
  14. 17 Sep, 2010 1 commit
  15. 14 Aug, 2010 1 commit
  16. 26 Jul, 2010 1 commit
  17. 23 Jul, 2010 2 commits
  18. 22 Jul, 2010 1 commit
    • Thomas Renninger's avatar
      x86 cpufreq, perf: Make trace_power_frequency cpufreq driver independent · 4c21adf2
      Thomas Renninger authored
      and fix the broken case if a core's frequency depends on others.
      
      trace_power_frequency was only implemented in a rather ungeneric
      way in acpi-cpufreq driver's target() function only.
      
      -> Move the call to trace_power_frequency to
         cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE
         notifier is triggered.
         This will support power frequency tracing by all cpufreq
         drivers.
      
      trace_power_frequency did not trace frequency changes correctly
      when the userspace governor was used or when CPU cores'
      frequency depend on each other.
      
      -> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu
         which gets switched automatically fixes this.
      
      Robert Schoene provided some important fixes on top of my
      initial quick shot version which are integrated in this patch:
      - Forgot some changes in power_end trace (TP_printk/variable names)
      - Variable dummy in power_end must now be cpu_id
      - Use static 64 bit variable instead of unsigned int for cpu_id
      
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      Cc: davej@codemonkey.org.uk
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Acked-by: default avatarArjan van de Ven <arjan@infradead.org>
      Cc: Robert Schoene <robert.schoene@tu-dresden.de>
      Tested-by: default avatarRobert Schoene <robert.schoene@tu-dresden.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      4c21adf2
  19. 28 May, 2010 1 commit
    • Len Brown's avatar
      intel_idle: native hardware cpuidle driver for latest Intel processors · 26717172
      Len Brown authored
      This EXPERIMENTAL driver supersedes acpi_idle on
      Intel Atom Processors, Intel Core i3/i5/i7 Processors
      and associated Intel Xeon processors.
      
      It does not support the Intel Core2 processor or earlier.
      
      For kernels configured with ACPI, CONFIG_INTEL_IDLE=y
      allows intel_idle to probe before the ACPI processor driver.
      Booting with "intel_idle.max_cstate=0" disables intel_idle
      and the system will fall back on ACPI's "acpi_idle".
      
      Typical Linux distributions load ACPI processor module early,
      making CONFIG_INTEL_IDLE=m not easily useful on ACPI platforms.
      
      intel_idle probes all processors at module_init time.
      Processors that are hot-added later will be limited
      to using C1 in idle.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      26717172