1. 25 8月, 2010 1 次提交
    • R
      ACPI/PCI: Do not preserve _OSC control bits returned by a query · 2b8fd918
      Rafael J. Wysocki 提交于
      There is the assumption in acpi_pci_osc_control_set() that it is
      always sufficient to compare the mask of _OSC control bits to be
      requested with the result of an _OSC query where all of the known
      control bits have been checked.  However, in general, that need not
      be the case.  For example, if an _OSC feature A depends on an _OSC
      feature B and control of A, B plus another _OSC feature C is
      requested simultaneously, the BIOS may return A, B, C, while it would
      only return C if A and C were requested without B.
      
      That may result in passing a wrong mask of _OSC control bits to an
      _OSC control request, in which case the BIOS may only grant control
      of a subset of the requested features.  Moreover, acpi_pci_run_osc()
      will return error code if that happens and the caller of
      acpi_pci_osc_control_set() will not know that it's been granted
      control of some _OSC features.  Consequently, the system will
      generally not work as expected.
      
      Apart from this acpi_pci_osc_control_set() always uses the mask
      of _OSC control bits returned by the very first invocation of
      acpi_pci_query_osc(), but that is done with the second argument
      equal to OSC_PCI_SEGMENT_GROUPS_SUPPORT which generally happens
      to affect the returned _OSC control bits.
      
      For these reasons, make acpi_pci_osc_control_set() always check if
      control of the requested _OSC features will be granted before making
      the final control request.  As a result, the osc_control_qry and
      osc_queried members of struct acpi_pci_root are not necessary any
      more, so drop them and remove the remaining code referring to them.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2b8fd918
  2. 04 4月, 2010 1 次提交
    • B
      ACPI: pci_root: save downstream bus range · 6ad95513
      Bjorn Helgaas 提交于
      Previously, we only saved the root bus number, i.e., the beginning of the
      downstream bus range.  We now support IORESOURCE_BUS resources, so this
      patch uses that to keep track of both the beginning and the end of the
      downstream bus range.
      
      It's important to know both the beginning and the end for supporting _CBA
      (see PCI Firmware spec, rev 3.0, sec 4.1.3) and so we know the limits for
      any possible PCI bus renumbering (we can't renumber downstream buses to be
      outside the bus number range claimed by the host bridge).
      
      It's clear from the spec that the bus range is supposed to be in _CRS, but
      if we don't find it there, we'll assume [_BBN - 0xFF] or [0 - 0xFF].
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      6ad95513
  3. 23 2月, 2010 2 次提交
    • R
      PCI / ACPI / PM: Platform support for PCI PME wake-up · b67ea761
      Rafael J. Wysocki 提交于
      Although the majority of PCI devices can generate PMEs that in
      principle may be used to wake up devices suspended at run time,
      platform support is generally necessary to convert PMEs into wake-up
      events that can be delivered to the kernel.  If ACPI is used for this
      purpose, PME signals generated by a PCI device will trigger the ACPI
      GPE associated with the device to generate an ACPI wake-up event that
      we can set up a handler for, provided that everything is configured
      correctly.
      
      Unfortunately, the subset of PCI devices that have GPEs associated
      with them is quite limited.  The devices without dedicated GPEs have
      to rely on the GPEs associated with other devices (in the majority of
      cases their upstream bridges and, possibly, the root bridge) to
      generate ACPI wake-up events in response to PME signals from them.
      
      Add ACPI platform support for PCI PME wake-up:
      o Add a framework making is possible to use ACPI system notify
        handlers for run-time PM.
      o Add new PCI platform callback ->run_wake() to struct
        pci_platform_pm_ops allowing us to enable/disable the platform to
        generate wake-up events for given device.  Implemet this callback
        for the ACPI platform.
      o Define ACPI wake-up handlers for PCI devices and PCI root buses and
        make the PCI-ACPI binding code register wake-up notifiers for all
        PCI devices present in the ACPI tables.
      o Add function pci_dev_run_wake() which can be used by PCI drivers to
        check if given device is capable of generating wake-up events at
        run time.
      
      Developed in cooperation with Matthew Garrett <mjg@redhat.com>.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b67ea761
    • R
      ACPI / PM: Add more run-time wake-up fields · f517709d
      Rafael J. Wysocki 提交于
      Use the run_wake flag to mark all devices for which run-time wake-up
      events may be generated by the platform.  Introduce a new wake-up
      flag, always_enabled, for marking devices that should be permanently
      enabled to generate run-time events.  Also, introduce a reference
      counter for run-wake devices and a function that will initialize all
      of the run-time wake-up fields for given device.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f517709d
  4. 28 1月, 2010 1 次提交
  5. 26 9月, 2009 7 次提交
  6. 20 9月, 2009 1 次提交
  7. 10 9月, 2009 2 次提交
  8. 29 8月, 2009 1 次提交
  9. 27 8月, 2009 2 次提交
  10. 26 6月, 2009 1 次提交
  11. 18 6月, 2009 3 次提交
  12. 13 6月, 2009 1 次提交
  13. 07 4月, 2009 1 次提交
  14. 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
  15. 28 3月, 2009 3 次提交
  16. 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
  17. 11 10月, 2008 2 次提交
  18. 24 9月, 2008 1 次提交
  19. 17 7月, 2008 1 次提交
  20. 09 7月, 2008 1 次提交
  21. 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
  22. 12 6月, 2008 1 次提交
  23. 07 2月, 2008 1 次提交
  24. 02 2月, 2008 1 次提交