1. 12 6月, 2010 2 次提交
    • R
      ACPI / ACPICA: Avoid writing full enable masks to GPE registers · c9a8bbb7
      Rafael J. Wysocki 提交于
      ACPICA uses acpi_hw_write_gpe_enable_reg() to re-enable a GPE after
      an event signaled by it has been handled.  However, this function
      writes the entire GPE enable mask to the GPE's enable register which
      may not be correct.  Namely, if one of the other GPEs in the same
      register was previously enabled by acpi_enable_gpe() and subsequently
      disabled using acpi_set_gpe(), acpi_hw_write_gpe_enable_reg() will
      re-enable it along with the target GPE.
      
      To fix this issue rework acpi_hw_write_gpe_enable_reg() so that it
      calls acpi_hw_low_set_gpe() with a special action value,
      ACPI_GPE_COND_ENABLE, that will make it only enable the GPE if the
      corresponding bit in its register's enable_for_run mask is set.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      c9a8bbb7
    • R
      ACPI / ACPICA: Fix low-level GPE manipulation code · fd247447
      Rafael J. Wysocki 提交于
      ACPICA uses acpi_ev_enable_gpe() for enabling GPEs at the low level,
      which is incorrect, because this function only enables the GPE if the
      corresponding bit in its enable register's enable_for_run mask is set.
      This causes acpi_set_gpe() to work incorrectly if used for enabling
      GPEs that were not previously enabled with acpi_enable_gpe().  As a
      result, among other things, wakeup-only GPEs are never enabled by
      acpi_enable_wakeup_device(), so the devices that use them are unable
      to wake up the system.
      
      To fix this issue remove acpi_ev_enable_gpe() and its counterpart
      acpi_ev_disable_gpe() and replace acpi_hw_low_disable_gpe() with
      acpi_hw_low_set_gpe() that will be used instead to manipulate GPE
      enable bits at the low level.  Make the users of acpi_ev_enable_gpe()
      and acpi_ev_disable_gpe() call acpi_hw_low_set_gpe() instead and
      make sure that GPE enable masks are only updated by acpi_enable_gpe()
      and acpi_disable_gpe() when GPE reference counters change from 0
      to 1 and from 1 to 0, respectively.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      fd247447
  2. 06 5月, 2010 1 次提交
  3. 20 4月, 2010 1 次提交
  4. 23 2月, 2010 1 次提交
    • R
      ACPI: Use GPE reference counting to support shared GPEs · 9630bdd9
      Rafael J. Wysocki 提交于
      ACPI GPEs may map to multiple devices.  The current GPE interface
      only provides a mechanism for enabling and disabling GPEs, making
      it difficult to change the state of GPEs at runtime without extensive
      cooperation between devices.
      
      Add an API to allow devices to indicate whether or not they want
      their device's GPE to be enabled for both runtime and wakeup events.
      
      Remove the old GPE type handling entirely, which gets rid of various
      quirks, like the implicit disabling with GPE type setting. This
      requires a small amount of rework in order to ensure that non-wake
      GPEs are enabled by default to preserve existing behaviour.
      
      Based on patches from Matthew Garrett <mjg@redhat.com>.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9630bdd9
  5. 23 1月, 2010 3 次提交
  6. 21 9月, 2009 1 次提交
  7. 27 8月, 2009 3 次提交
  8. 27 5月, 2009 1 次提交
  9. 28 3月, 2009 1 次提交
  10. 27 3月, 2009 1 次提交
  11. 06 1月, 2009 1 次提交
  12. 31 12月, 2008 3 次提交
  13. 30 12月, 2008 1 次提交
  14. 28 10月, 2008 1 次提交
    • Z
      ACPI: bugfix reporting of event handler status · ed206fac
      Zhang Rui 提交于
      Introduce a new flag showing whether the event has an event handler/method.
      
      For all the GPEs and Fixed Events,
       1. ACPI_EVENT_FLAG_HANDLE is cleared, it's an "invalid" ACPI event.
       2. Both ACPI_EVENT_FLAG_HANDLE and ACPI_EVENT_FLAG_DISABLE are set,
          it's "disabled".
       3. Both ACPI_EVENT_FLAG_HANDLE and ACPI_EVENT_FLAG_ENABLE are set,
          it's "enabled".
       4. Both ACPI_EVENT_FLAG_HANDLE and ACPI_EVENT_FLAG_WAKE_ENABLE are set,
          it's "wake_enabled".
      
      Among other things, this prevents incorrect reporting of ACPI events
      as being "invalid" when it's really just (temporarily) "disabled".
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      ed206fac
  15. 23 10月, 2008 3 次提交
  16. 17 7月, 2008 1 次提交
  17. 24 4月, 2008 1 次提交
  18. 23 4月, 2008 6 次提交
  19. 24 7月, 2007 1 次提交
  20. 10 5月, 2007 1 次提交
  21. 20 3月, 2007 1 次提交
    • L
      ACPI: IA64: fix %ll build warnings · 0cd4554d
      Len Brown 提交于
      acpi_integer is 64-bits on all platforms, and so was defined as a u64.
      
      i386 and x86_64 define u64 as unsigned long long.
      ia64 defines u64 as long.
      
      While these are all 64-bits, the kernel build warns about formating
      a "long" with %ll:
      
      drivers/ata/libata-acpi.c:176: warning: long long unsigned int format, acpi_integer arg (arg 5)
      
      So skip using "u64" and define acpi_integer as "unsigned long long"
      to make gcc happy with %ll.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      0cd4554d
  22. 03 2月, 2007 5 次提交