1. 10 9月, 2009 1 次提交
  2. 27 3月, 2009 1 次提交
  3. 20 3月, 2009 1 次提交
  4. 08 1月, 2009 6 次提交
  5. 31 12月, 2008 1 次提交
  6. 12 11月, 2008 1 次提交
    • K
      PCI: ignore bit0 of _OSC return code · 2485b867
      Kenji Kaneshige 提交于
      Currently acpi_run_osc() checks all the bits in _OSC result code (the
      first DWORD in the capabilities buffer) to see error condition. But the
      bit 0, which doesn't indicate any error, must be ignored.
      
      The bit 0 is used as the query flag at _OSC invocation time. Some
      platforms clear it during _OSC evaluation, but the others don't. On
      latter platforms, current acpi_run_osc() mis-detects error when _OSC is
      evaluated with query flag set because it doesn't ignore the bit 0.
      Because of this, the __acpi_query_osc() always fails on such platforms.
      
      And this is the cause of the problem that pci_osc_control_set() doesn't
      work since the commit 4e39432f which
      changed pci_osc_control_set() to use __acpi_query_osc().
      Tested-by: N"Tomasz Czernecki <czernecki@gmail.com>
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2485b867
  7. 25 10月, 2008 1 次提交
  8. 23 10月, 2008 4 次提交
  9. 29 7月, 2008 1 次提交
  10. 17 7月, 2008 2 次提交
  11. 08 7月, 2008 3 次提交
    • 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
      PCI: rework pci_set_power_state function to call platform first · 44e4e66e
      Rafael J. Wysocki 提交于
      Rework pci_set_power_state() so that the platform callback is
      invoked before the native mechanism, if necessary.  Also, make
      the function check if the device is power manageable by the
      platform before invoking the platform callback.
      
      This may matter if the device dependent on additional power
      resources controlled by the platform is being put into D0, in which
      case those power resources must be turned on before we attempt to
      handle the device itself.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      44e4e66e
    • R
      PCI: Introduce platform_pci_power_manageable function · 961d9120
      Rafael J. Wysocki 提交于
      Introduce function pointer platform_pci_power_manageable to be used
      by the platform-related code to point to a function allowing us to
      check if given device is power manageable by the platform.
      
      Introduce acpi_pci_power_manageable() playing that role for ACPI.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      961d9120
  12. 28 6月, 2008 1 次提交
    • T
      Fix forcedeth hibernate/wake-on-lan problems · f5ccbcfa
      Tobias Diedrich 提交于
      This patch is the minimal amount of code needed to support
      wake-on-lan in platform mode properly (i.e. "ethtool -s eth0 wol g"
      is sufficient, no additional magic needed) for me.
      
      This is derived from David Brownells patch
      (http://lists.laptop.org/pipermail/devel/2007-April/004691.html).
      However I decided to move the hook into pci-acpi.c since the other
      two pci hooks also live there and pci and acpi are the only users of
      the platform_enable_wakeup-hook.
      
      As a 'side-effect' this also makes wake on usb activity work for me
      and I had to disable usb wakeup (which is enabled by default) using
      the power/wakeup sysfs functionality ("echo disabled >
      ${sysfs_path_to_device}/power/wakeup").
      
      (BTW I first thought the 'immediate reboot because of usb wake' effect is
      caused by the optical mouse generating a wake event, but it rather
      seems to be a problem with a flaky secondary usb host controller,
      which sees a connected device where nothing is attached)
      Signed-off-by: NTobias Diedrich <ranma+kernel@tdiedrich.de>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      f5ccbcfa
  13. 12 6月, 2008 2 次提交
  14. 11 6月, 2008 5 次提交
  15. 14 5月, 2008 4 次提交
  16. 23 2月, 2008 1 次提交
  17. 22 2月, 2008 1 次提交
  18. 21 2月, 2008 1 次提交
  19. 16 2月, 2008 1 次提交
  20. 02 2月, 2008 2 次提交