1. 20 9月, 2009 1 次提交
  2. 10 9月, 2009 2 次提交
  3. 18 6月, 2009 3 次提交
  4. 13 6月, 2009 1 次提交
  5. 07 4月, 2009 1 次提交
  6. 05 4月, 2009 1 次提交
    • B
      ACPI: support acpi_device_ops .notify methods · 46ec8598
      Bjorn Helgaas 提交于
      This patch adds support for ACPI device driver .notify() methods.  If
      such a method is present, Linux/ACPI installs a handler for device
      notifications (but not for system notifications such as Bus Check,
      Device Check, etc).  When a device notification occurs, Linux/ACPI
      passes it on to the driver's .notify() method.
      
      In most cases, this removes the need for drivers to install their own
      handlers for device-specific notifications.
      
      For fixed hardware devices like some power and sleep buttons, there's
      no notification value because there's no control method to execute a
      Notify opcode.  When a fixed hardware device generates an event, we
      handle it the same as a regular device notification, except we send
      a ACPI_FIXED_HARDWARE_EVENT value.  This is outside the normal 0x0-0xff
      range used by Notify opcodes.
      
      Several drivers install their own handlers for system Bus Check and
      Device Check notifications so they can support hot-plug.  This patch
      doesn't affect that usage.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Reviewed-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      46ec8598
  7. 28 3月, 2009 3 次提交
  8. 08 11月, 2008 1 次提交
    • T
      ACPI: video: Ignore devices that aren't present in hardware · 22c13f9d
      Thomas Renninger 提交于
      This is a reimplemention of commit
      0119509c
      from Matthew Garrett <mjg59@srcf.ucam.org>
      
      This patch got removed because of a regression: ThinkPads with a
      Intel graphics card and an Integrated Graphics Device BIOS implementation
      stopped working.
      In fact, they only worked because the ACPI device of the discrete, the
      wrong one, got used (via int10). So ACPI functions were poking on the wrong
      hardware used which is a sever bug.
      The next patch provides support for above ThinkPads to be able to
      switch brightness via the legacy thinkpad_acpi driver and automatically
      detect when to use it.
      
      Original commit message from Matthew Garrett:
          Vendors often ship machines with a choice of integrated or discrete
          graphics, and use the same DSDT for both. As a result, the ACPI video
          module will locate devices that may not exist on this specific platform.
          Attempt to determine whether the device exists or not, and abort the
          device creation if it doesn't.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=9614Signed-off-by: NThomas Renninger <trenn@suse.de>
      Acked-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      22c13f9d
  9. 11 10月, 2008 2 次提交
  10. 24 9月, 2008 1 次提交
  11. 17 7月, 2008 1 次提交
  12. 09 7月, 2008 1 次提交
  13. 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
      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_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
  14. 12 6月, 2008 1 次提交
  15. 07 2月, 2008 1 次提交
  16. 02 2月, 2008 1 次提交
  17. 25 1月, 2008 1 次提交
  18. 24 1月, 2008 1 次提交
  19. 26 10月, 2007 1 次提交
  20. 28 9月, 2007 2 次提交
  21. 24 8月, 2007 2 次提交
    • L
      ACPI: Schedule /proc/acpi/event for removal · 14e04fb3
      Len Brown 提交于
      Schedule /proc/acpi/event for removal in 6 months.
      
      Re-name acpi_bus_generate_event() to acpi_bus_generate_proc_event()
      to make sure there is no confusion that it is for /proc/acpi/event only.
      
      Add CONFIG_ACPI_PROC_EVENT to allow removal of /proc/acpi/event.
      There is no functional change if CONFIG_ACPI_PROC_EVENT=y
      Signed-off-by: NLen Brown <len.brown@intel.com>
      14e04fb3
    • Z
      ACPI: don't duplicate input events on netlink · 962ce8ca
      Zhang Rui 提交于
      The previous events patch added a netlink event for every
      user of the legacy /proc/acpi/event interface.
      
      However, some users of /proc/acpi/event are really input events,
      and they already report their events via the input layer.
      
      Introduce a new interface, acpi_bus_generate_netlink_event(),
      which is explicitly called by devices that want to repoprt
      events via netlink.  This allows the input-like events
      to opt-out of generating netlink events.  In summary:
      
      events that are sent via netlink:
      	ac/battery/sbs
      	thermal
      	processor
      	thinkpad_acpi dock/bay
      
      events that are sent via input layer:
      	button
      	video hotkey
      	thinkpad_acpi hotkey
      	asus_acpi/asus-laptop hotkey
      	sonypi/sonylaptop
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      962ce8ca
  22. 30 7月, 2007 1 次提交
    • R
      Introduce CONFIG_SUSPEND for suspend-to-Ram and standby · 296699de
      Rafael J. Wysocki 提交于
      Introduce CONFIG_SUSPEND representing the ability to enter system sleep
      states, such as the ACPI S3 state, and allow the user to choose SUSPEND
      and HIBERNATION independently of each other.
      
      Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has
      been chosen and the kernel is intended for SMP systems.
      
      Also, introduce CONFIG_PM_SLEEP which is automatically selected if
      CONFIG_SUSPEND or CONFIG_HIBERNATION is set and use it to select the
      code needed for both suspend and hibernation.
      
      The top-level power management headers and the ACPI code related to
      suspend and hibernation are modified to use the new definitions (the
      changes in drivers/acpi/sleep/main.c are, mostly, moving code to reduce
      the number of ifdefs).
      
      There are many other files in which CONFIG_PM can be replaced with
      CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in
      the future.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      296699de
  23. 24 7月, 2007 1 次提交
  24. 22 7月, 2007 1 次提交
  25. 04 7月, 2007 1 次提交
  26. 10 5月, 2007 1 次提交
  27. 09 5月, 2007 1 次提交
  28. 03 5月, 2007 1 次提交
  29. 03 2月, 2007 1 次提交
  30. 06 1月, 2007 1 次提交