1. 08 7月, 2008 4 次提交
    • R
      PCI ACPI: Rework PCI handling of wake-up · eb9d0fe4
      Rafael J. Wysocki 提交于
      * Introduce function acpi_pm_device_sleep_wake() for enabling and
        disabling the system wake-up capability of devices that are power
        manageable by ACPI.
      
      * Introduce function acpi_bus_can_wakeup() allowing other (dependent)
        subsystems to check if ACPI is able to enable the system wake-up
        capability of given device.
      
      * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and
        for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake().
      
      * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and
        for the ACPI 'driver' make it use acpi_bus_can_wakeup().
      
      * Move the PME# handlig code out of pci_enable_wake() and split it
        into two functions, pci_pme_capable() and pci_pme_active(),
        allowing the caller to check if given device is capable of
        generating PME# from given power state and to enable/disable the
        device's PME# functionality, respectively.
      
      * Modify pci_enable_wake() to use the new ACPI callbacks and the new
        PME#-related functions.
      
      * Drop the generic .platform_enable_wakeup() callback that is not
        used any more.
      
      * Introduce device_set_wakeup_capable() that will set the
        power.can_wakeup flag of given device.
      
      * Rework PCI device PM initialization so that, if given device is
        capable of generating wake-up events, either natively through the
        PME# mechanism, or with the help of the platform, its
        power.can_wakeup flag is set and its power.should_wakeup flag is
        unset as appropriate.
      
      * Make ACPI set the power.can_wakeup flag for devices found to be
        wake-up capable by it.
      
      * Make the ACPI wake-up code enable/disable GPEs for devices that
        have the wakeup.flags.prepared flag set (which means that their
        wake-up power has been enabled).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      eb9d0fe4
    • R
      ACPI: Introduce new device wakeup flag 'prepared' · 0af4b8c4
      Rafael J. Wysocki 提交于
      Introduce additional flag 'prepared' in struct acpi_device_wakeup_flags
      and use it to prevent devices from being enable/disabled do wake up the
      system multiple times in a row (this does not happen currently, but will
      be possible after some of the following patches).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0af4b8c4
    • R
      ACPI: Introduce acpi_device_sleep_wake function · 77e76609
      Rafael J. Wysocki 提交于
      The currect ACPI code attempts to execute _PSW at three different
      places and in one of them only it tries to execute _DSW before _PSW,
      which is inconsistent with the other two cases.
      
      Move the execution of _DSW and _PSW into a separate function called
      acpi_device_sleep_wake() and call it wherever appropriate instead of
      executing _DSW and/or _PSW directly.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      77e76609
    • R
      ACPI: Introduce acpi_bus_power_manageable function · 3737b2b1
      Rafael J. Wysocki 提交于
      Introduce function acpi_bus_power_manageable() allowing other
      (dependent) subsystems to check if ACPI is able to power manage given
      device.  This may be useful, for example, for PCI device power
      management.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      3737b2b1
  2. 13 6月, 2008 1 次提交
    • R
      Suspend-related patches for 2.6.27 · d8f3de0d
      Rafael J. Wysocki 提交于
      ACPI PM: Add possibility to change suspend sequence
      
      There are some systems out there that don't work correctly with
      our current suspend/hibernation code ordering.  Provide a workaround
      for these systems allowing them to pass 'acpi_sleep=old_ordering' in
      the kernel command line so that it will use the pre-ACPI 2.0 ("old")
      suspend code ordering.
      
      Unfortunately, this requires us to add a platform hook to the
      resuming of devices for recovering the platform in case one of the
      device drivers' .suspend() routines returns error code.  Namely,
      ACPI 1.0 specifies that _PTS should be called before suspending
      devices, but _WAK still should be called before resuming them in
      order to undo the changes made by _PTS.  However, if there is an
      error during suspending devices, they are automatically resumed
      without returning control to the PM core, so the _WAK has to be
      called from within device_resume() in that cases.
      
      The patch also reorders and refactors the ACPI suspend/hibernation
      code to avoid duplication as far as reasonably possible.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d8f3de0d
  3. 12 6月, 2008 2 次提交
  4. 11 6月, 2008 1 次提交
  5. 23 5月, 2008 1 次提交
  6. 01 5月, 2008 2 次提交
  7. 30 4月, 2008 1 次提交
    • A
      [IA64] Provide ACPI fixup for /proc/cpuinfo/physical_id · fe086a7b
      Alex Chiang 提交于
      Legacy HP ia64 platforms currently cannot provide
      /proc/cpuinfo/physical_id due to legacy SAL/PAL implementations.
      However, that physical topology information can be obtained
      via ACPI.
      
      Provide an interface that gives ACPI one last chance to provide
      physical_id for these legacy platforms. This logic only comes
      into play iff:
      
      - ACPI actually provides slot information for the CPU
      - we lack a valid socket_id
      
      Otherwise, we don't do anything.
      
      Since x86 uses the ACPI processor driver as well, we provide a nop
      stub function for arch_fix_phys_package_id() in asm-x86/topology.h
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      fe086a7b
  8. 29 4月, 2008 16 次提交
  9. 28 4月, 2008 1 次提交
  10. 27 4月, 2008 2 次提交
    • P
      fix idle (arch, acpi and apm) and lockdep · 7f424a8b
      Peter Zijlstra 提交于
      OK, so 25-mm1 gave a lockdep error which made me look into this.
      
      The first thing that I noticed was the horrible mess; the second thing I
      saw was hacks like: 71e93d15
      
      The problem is that arch idle routines are somewhat inconsitent with
      their IRQ state handling and instead of fixing _that_, we go paper over
      the problem.
      
      So the thing I've tried to do is set a standard for idle routines and
      fix them all up to adhere to that. So the rules are:
      
        idle routines are entered with IRQs disabled
        idle routines will exit with IRQs enabled
      
      Nearly all already did this in one form or another.
      
      Merge the 32 and 64 bit bits so they no longer have different bugs.
      
      As for the actual lockdep warning; __sti_mwait() did a plainly un-annotated
      irq-enable.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7f424a8b
    • R
      x86: validate against acpi motherboard resources · 7752d5cf
      Robert Hancock 提交于
      This path adds validation of the MMCONFIG table against the ACPI reserved
      motherboard resources.  If the MMCONFIG table is found to be reserved in
      ACPI, we don't bother checking the E820 table.  The PCI Express firmware
      spec apparently tells BIOS developers that reservation in ACPI is required
      and E820 reservation is optional, so checking against ACPI first makes
      sense.  Many BIOSes don't reserve the MMCONFIG region in E820 even though
      it is perfectly functional, the existing check needlessly disables MMCONFIG
      in these cases.
      
      In order to do this, MMCONFIG setup has been split into two phases.  If PCI
      configuration type 1 is not available then MMCONFIG is enabled early as
      before.  Otherwise, it is enabled later after the ACPI interpreter is
      enabled, since we need to be able to execute control methods in order to
      check the ACPI reserved resources.  Presently this is just triggered off
      the end of ACPI interpreter initialization.
      
      There are a few other behavioral changes here:
      
      - Validate all MMCONFIG configurations provided, not just the first one.
      
      - Validate the entire required length of each configuration according to
        the provided ending bus number is reserved, not just the minimum required
        allocation.
      
      - Validate that the area is reserved even if we read it from the chipset
        directly and not from the MCFG table.  This catches the case where the
        BIOS didn't set the location properly in the chipset and has mapped it
        over other things it shouldn't have.
      
      This also cleans up the MMCONFIG initialization functions so that they
      simply do nothing if MMCONFIG is not compiled in.
      
      Based on an original patch by Rajesh Shah from Intel.
      
      [akpm@linux-foundation.org: many fixes and cleanups]
      Signed-off-by: NRobert Hancock <hancockr@shaw.ca>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NAndi Kleen <ak@suse.de>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7752d5cf
  11. 25 4月, 2008 2 次提交
  12. 24 4月, 2008 1 次提交
  13. 23 4月, 2008 6 次提交