This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 10 Jul, 2012 1 commit
    • Preeti U Murthy's avatar
      PM / cpuidle: System resume hang fix with cpuidle · 8651f97b
      Preeti U Murthy authored
      On certain bios, resume hangs if cpus are allowed to enter idle states
      during suspend [1].
      
      This was fixed in apci idle driver [2].But intel_idle driver does not
      have this fix. Thus instead of replicating the fix in both the idle
      drivers, or in more platform specific idle drivers if needed, the
      more general cpuidle infrastructure could handle this.
      
      A suspend callback in cpuidle_driver could handle this fix. But
      a cpuidle_driver provides only basic functionalities like platform idle
      state detection capability and mechanisms to support entry and exit
      into CPU idle states. All other cpuidle functions are found in the
      cpuidle generic infrastructure for good reason that all cpuidle
      drivers, irrepective of their platforms will support these functions.
      
      One option therefore would be to register a suspend callback in cpuidle
      which handles this fix. This could be called through a PM_SUSPEND_PREPARE
      notifier. But this is too generic a notfier for a driver to handle.
      
      Also, ideally the job of cpuidle is not to handle side effects of suspend.
      It should expose the interfaces which "handle cpuidle 'during' suspend"
      or any other operation, which the subsystems call during that respective
      operation.
      
      The fix demands that during suspend, no cpus should be allowed to enter
      deep C-states. The interface cpuidle_uninstall_idle_handler() in cpuidle
      ensures that. Not just that it also kicks all the cpus which are already
      in idle out of their idle states which was being done during cpu hotplug
      through a CPU_DYING_FROZEN callbacks.
      
      Now the question arises about when during suspend should
      cpuidle_uninstall_idle_handler() be called. Since we are dealing with
      drivers it seems best to call this function during dpm_suspend().
      Delaying the call till dpm_suspend_noirq() does no harm, as long as it is
      before cpu_hotplug_begin() to avoid race conditions with cpu hotpulg
      operations. In dpm_suspend_noirq(), it would be wise to place this call
      before suspend_device_irqs() to avoid ugly interactions with the same.
      
      Ananlogously, during resume.
      
      References:
      [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674075.
      [2] http://marc.info/?l=linux-pm&m=133958534231884&w=2
      
      
      
      Reported-and-tested-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: default avatarPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Reviewed-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      8651f97b
  2. 03 Jul, 2012 1 commit
  3. 08 May, 2012 1 commit
  4. 06 Apr, 2012 1 commit
  5. 30 Mar, 2012 3 commits
  6. 21 Mar, 2012 1 commit
  7. 13 Feb, 2012 1 commit
  8. 21 Dec, 2011 1 commit
    • Kay Sievers's avatar
      cpu: convert 'cpu' and 'machinecheck' sysdev_class to a regular subsystem · 8a25a2fd
      Kay Sievers authored
      
      
      This moves the 'cpu sysdev_class' over to a regular 'cpu' subsystem
      and converts the devices to regular devices. The sysdev drivers are
      implemented as subsystem interfaces now.
      
      After all sysdev classes are ported to regular driver core entities, the
      sysdev implementation will be entirely removed from the kernel.
      
      Userspace relies on events and generic sysfs subsystem infrastructure
      from sysdev devices, which are made available with this conversion.
      
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8a25a2fd
  9. 07 Nov, 2011 4 commits
  10. 31 Oct, 2011 1 commit
  11. 25 Aug, 2011 1 commit
  12. 03 Aug, 2011 3 commits
  13. 12 Jan, 2011 4 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
    • Len Brown's avatar
      cpuidle: delete NOP CPUIDLE_FLAG_POLL · d247632c
      Len Brown authored
      
      
      it serves no purpose
      
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      d247632c
    • Thomas Renninger's avatar
      cpuidle: Rename X86 specific idle poll state[0] from C0 to POLL · 720f1c30
      Thomas Renninger authored
      
      
      C0 means and is well know as "not idle".
      All documentation out there uses this term as "running"/"not idle"
      state. Also Linux userspace tools (e.g. cpufreq-aperf and turbostat)
      show C0 residency which there is correct, but means something totally
      else than cpuidle "POLL" state.
      
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      720f1c30
    • Rafael J. Wysocki's avatar
      cpuidle: Make cpuidle_enable_device() call poll_idle_init() · d8c216cf
      Rafael J. Wysocki authored
      
      
      The following scenario is possible with the current cpuidle code and
      the ACPI cpuidle driver:
      (1) acpi_processor_cst_has_changed() is called,
      (2) cpuidle_disable_device() is called,
      (3) cpuidle_remove_state_sysfs() is called to remove the (presumably
          outdated) states info from sysfs,
      (3) acpi_processor_get_power_info() is called, the first entry in the
          pr->power.states[] table is filled with zeros,
      (4) acpi_processor_setup_cpuidle() is called and it doesn't fill the
          first entry in pr->power.states[],
      (5) cpuidle_enable_device() is called,
      (6) __cpuidle_register_device() is _not_ called, since the device has
          already been registered,
      (7) Consequently, poll_idle_init() is _not_ called either,
      (8) cpuidle_add_state_sysfs() is called to create the sysfs attributes
          for the new states and it uses the bogus first table entry from
          acpi_processor_get_power_info() for creating state0.
      
      This problem is avoided if cpuidle_enable_device()
      unconditionally calls poll_idle_init().
      
      Reported-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      cc: stable@kernel.org
      d8c216cf
  14. 04 Jan, 2011 1 commit
    • Thomas Renninger's avatar
      perf: Clean up power events by introducing new, more generic ones · 25e41933
      Thomas Renninger authored
      
      
      Add these new power trace events:
      
       power:cpu_idle
       power:cpu_frequency
       power:machine_suspend
      
      The old C-state/idle accounting events:
        power:power_start
        power:power_end
      
      Have now a replacement (but we are still keeping the old
      tracepoints for compatibility):
      
        power:cpu_idle
      
      and
        power:power_frequency
      
      is replaced with:
        power:cpu_frequency
      
      power:machine_suspend is newly introduced.
      
      Jean Pihet has a patch integrated into the generic layer
      (kernel/power/suspend.c) which will make use of it.
      
      the type= field got removed from both, it was never
      used and the type is differed by the event type itself.
      
      perf timechart userspace tool gets adjusted in a separate patch.
      
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Acked-by: default avatarJean Pihet <jean.pihet@newoldbits.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: rjw@sisk.pl
      LKML-Reference: <1294073445-14812-3-git-send-email-trenn@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      LKML-Reference: <1290072314-31155-2-git-send-email-trenn@suse.de>
      25e41933
  15. 17 Dec, 2010 1 commit
    • Christoph Lameter's avatar
      drivers: Replace __get_cpu_var with __this_cpu_read if not used for an address. · 4a6f4fe8
      Christoph Lameter authored
      
      
      __get_cpu_var() can be replaced with this_cpu_read and will then use a single
      read instruction with implied address calculation to access the correct per cpu
      instance.
      
      However, the address of a per cpu variable passed to __this_cpu_read() cannot be
      determed (since its an implied address conversion through segment prefixes).
      Therefore apply this only to uses of __get_cpu_var where the addres of the
      variable is not used.
      
      V3->V4:
      	- Move one instance of this_cpu_inc_return to a later patch
      	  so that this one can go in without percpu infrastructrure
      	  changes.
      
      Sedat: fixed compile failure caused by an extra ')'.
      
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Sedat Dilek <sedat.dilek@gmail.com>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      4a6f4fe8
  16. 10 Aug, 2010 1 commit
    • Ai Li's avatar
      cpuidle: extend cpuidle and menu governor to handle dynamic states · 71abbbf8
      Ai Li authored
      
      
      On some SoC chips, HW resources may be in use during any particular idle
      period.  As a consequence, the cpuidle states that the SoC is safe to
      enter can change from idle period to idle period.  In addition, the
      latency and threshold of each cpuidle state can vary, depending on the
      operating condition when the CPU becomes idle, e.g.  the current cpu
      frequency, the current state of the HW blocks, etc.
      
      cpuidle core and the menu governor, in the current form, are geared
      towards cpuidle states that are static, i.e.  the availabiltiy of the
      states, their latencies, their thresholds are non-changing during run
      time.  cpuidle does not provide any hook that cpuidle drivers can use to
      adjust those values on the fly for the current idle period before the menu
      governor selects the target cpuidle state.
      
      This patch extends cpuidle core and the menu governor to handle states
      that are dynamic.  There are three additions in the patch and the patch
      maintains backwards-compatibility with existing cpuidle drivers.
      
      1) add prepare() to struct cpuidle_device.  A cpuidle driver can hook
         into the callback and cpuidle will call prepare() before calling the
         governor's select function.  The callback gives the cpuidle driver a
         chance to update the dynamic information of the cpuidle states for the
         current idle period, e.g.  state availability, latencies, thresholds,
         power values, etc.
      
      2) add CPUIDLE_FLAG_IGNORE as one of the state flags.  In the prepare()
         function, a cpuidle driver can set/clear the flag to indicate to the
         menu governor whether a cpuidle state should be ignored, i.e.  not
         available, during the current idle period.
      
      3) add power_specified bit to struct cpuidle_device.  The menu governor
         currently assumes that the cpuidle states are arranged in the order of
         increasing latency, threshold, and power savings.  This is true or can
         be made true for static states.  Once the state parameters are dynamic,
         the latencies, thresholds, and power savings for the cpuidle states can
         increase or decrease by different amounts from idle period to idle
         period.  So the assumption of increasing latency, threshold, and power
         savings from Cn to C(n+1) can no longer be guaranteed.
      
      It can be straightforward to calculate the power consumption of each
      available state and to specify it in power_usage for the idle period.
      Using the power_usage fields, the menu governor then selects the state
      that has the lowest power consumption and that still satisfies all other
      critieria.  The power_specified bit defaults to 0.  For existing cpuidle
      drivers, cpuidle detects that power_specified is 0 and fills in a dummy
      set of power_usage values.
      
      Signed-off-by: default avatarAi Li <aili@codeaurora.org>
      Cc: Len Brown <len.brown@intel.com>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      71abbbf8
  17. 03 Aug, 2010 1 commit
    • Thomas Renninger's avatar
      [CPUFREQ] x86 cpufreq: Make trace_power_frequency cpufreq driver independent · 6f4f2723
      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
      
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      CC: davej@redhat.com
      CC: arjan@infradead.org
      CC: linux-kernel@vger.kernel.org
      CC: robert.schoene@tu-dresden.de
      Tested-by: default avatar <robert.schoene@tu-dresden.de>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      6f4f2723
  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
      cpuidle: make cpuidle_curr_driver static · 752138df
      Len Brown authored
      
      
      cpuidle_register_driver() sets cpuidle_curr_driver
      cpuidle_unregister_driver() clears cpuidle_curr_driver
      
      We should't expose cpuidle_curr_driver to
      potential modification except via these interfaces.
      So make it static and create cpuidle_get_driver() to observe it.
      
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      752138df
  20. 29 Oct, 2009 1 commit
    • Kevin Hilman's avatar
      cpuidle: always return with interrupts enabled · 246eb7f0
      Kevin Hilman authored
      
      
      In the case where cpuidle_idle_call() returns before changing state due to
      a need_resched(), it was returning with IRQs disabled.
      
      The idle path assumes that the platform specific idle code returns with
      interrupts enabled (although this too is undocumented AFAICT) and on ARM
      we have a WARN_ON(!(irqs_disabled()) when returning from the idle loop, so
      the user-visible effects were only a warning since interrupts were
      eventually re-enabled later.
      
      On x86, this same problem exists, but there is no WARN_ON() to detect it.
      As on ARM, the interrupts are eventually re-enabled, so I'm not sure of
      any actual bugs triggered by this.  It's primarily a
      correctness/consistency fix.
      
      This patch ensures IRQs are (re)enabled before returning.
      
      Reported-by: default avatarHemanth V <hemanthv@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Tested-by: default avatarMartin Michlmayr <tbm@cyrius.com>
      Cc: <stable@kernel.org>		[2.6.31.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      246eb7f0
  21. 19 Sep, 2009 1 commit
    • Arjan van de Ven's avatar
      tracing, x86, cpuidle: Move the end point of a C state in the power tracer · 288f023e
      Arjan van de Ven authored
      
      
      The "end of a C state" trace point currently happens before
      the code runs that corrects the TSC for having stopped during idle.
      
      The result of this is that the timestamp of the end-of-C-state event
      is garbage on cpus where the TSC stops during idle.
      
      This patch moves the end point of the C state to after the timekeeping
      engine of the kernel has been corrected.
      
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: fweisbec@gmail.com
      Cc: peterz@infradead.org
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <20090919133533.139c2a46@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      288f023e
  22. 10 Nov, 2008 1 commit
  23. 16 Oct, 2008 2 commits
  24. 11 Sep, 2008 1 commit
    • Arjan van de Ven's avatar
      hrtimer: peek at the timer queue just before going idle · 2e94d1f7
      Arjan van de Ven authored
      
      
      As part of going idle, we already look at the time of the next timer event to determine
      which C-state to select etc.
      
      This patch adds functionality that causes the timers that are past their
      soft expire time, to fire at this time, before we calculate the next wakeup
      time. This functionality will thus avoid wakeups by running timers before
      going idle rather than specially waking up for it.
      
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      2e94d1f7
  25. 28 Jul, 2008 1 commit
  26. 26 Jun, 2008 1 commit
  27. 11 Jun, 2008 1 commit
    • Venkatesh Pallipadi's avatar
      cpuidle acpi driver: fix oops on AC<->DC · dcb84f33
      Venkatesh Pallipadi authored
      cpuidle and acpi driver interaction bug with the way cpuidle_register_driver()
      is called. Due to this bug, there will be oops on
      AC<->DC on some systems, where they support C-states in one DC and not in AC.
      
      The current code does
      ON BOOT:
      	Look at CST and other C-state info to see whether more than C1 is
      	supported. If it is, then acpi processor_idle does a
      	cpuidle_register_driver() call, which internally enables the device.
      
      ON CST change notification (AC<->DC) and on suspend-resume:
      	acpi driver temporarily disables device, updates the device with
      	any new C-states, and reenables the device.
      
      The problem is is on boot, there are no C2, C3 states supported and we skip
      the register. Later on AC<->DC, we may get a CST notification and we try
      to reevaluate CST and enabled the device, without actually registering it.
      This causes breakage as we try to create /sys fs sub directory, without the
      parent directory which is created at register time.
      
      Thanks to Sanjeev for reporting the problem here.
      http://bugzilla.kernel.org/show_bug.cgi?id=10394
      
      
      
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      dcb84f33
  28. 26 Mar, 2008 2 commits