1. 16 6月, 2013 1 次提交
  2. 02 6月, 2013 1 次提交
  3. 12 3月, 2013 1 次提交
  4. 25 1月, 2013 1 次提交
  5. 10 1月, 2013 3 次提交
  6. 15 11月, 2012 1 次提交
  7. 21 9月, 2012 2 次提交
  8. 14 7月, 2012 1 次提交
  9. 22 3月, 2012 1 次提交
  10. 17 1月, 2012 1 次提交
  11. 03 3月, 2011 1 次提交
  12. 25 2月, 2011 1 次提交
    • R
      ACPI / ACPICA: Implicit notify for multiple devices · 981858bd
      Rafael J. Wysocki 提交于
      Commit bba63a29 (ACPICA: Implicit notify support) introduced a
      mechanism that causes a notify request of type
      ACPI_NOTIFY_DEVICE_WAKE to be queued automatically by
      acpi_ev_asynch_execute_gpe_method() for the device whose _PRW points
      to the GPE being handled if that GPE is not associated with an
      _Lxx/_Exx method.  However, it turns out that on some systems there
      are multiple devices with _PRW pointing to the same GPE without
      _Lxx/_Exx and the mechanism introduced by commit bba63a29 needs to be
      extended so that "implicit" notify requests of type
      ACPI_NOTIFY_DEVICE_WAKE can be queued automatically for all those
      devices at the same time.
      Reported-and-tested-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      981858bd
  13. 19 1月, 2011 2 次提交
  14. 12 1月, 2011 6 次提交
  15. 07 8月, 2010 1 次提交
    • R
      ACPI / ACPICA: Fix reference counting problems with GPE handlers · 28f4f8a9
      Rafael J. Wysocki 提交于
      If a handler is installed for a GPE associated with an AML method and
      such that it cannot wake up the system from sleep states, the GPE
      remains enabled after the handler has been installed, although it
      should be disabled in that case to avoid spurious execution of the
      handler.
      
      Fix this issue by making acpi_install_gpe_handler() disable GPEs
      that were previously associated with AML methods and cannot wake up
      the system from sleep states.
      
      Analogously, make acpi_remove_gpe_handler() enable the GPEs that
      are associated with AML methods after their handlers have been
      removed and cannot wake up the system from sleep states.  In addition
      to that, fix a code ordering issue in acpi_remove_gpe_handler() that
      renders the locking ineffective (ACPI_MTX_EVENTS is released
      temporarily in the middle of the routine to wait for the completion
      of events already in progress).
      
      For this purpose introduce acpi_raw_disable_gpe() and
      acpi_raw_enable_gpe() to be called with acpi_gbl_gpe_lock held
      and rework acpi_disable_gpe() and acpi_enable_gpe(), respectively, to
      use them.  Also rework acpi_gpe_can_wake() to use
      acpi_raw_disable_gpe() instead of calling acpi_disable_gpe() after
      releasing the lock to avoid the possible theoretical race with
      acpi_install_gpe_handler().
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: "Moore, Robert" <robert.moore@intel.com>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      28f4f8a9
  16. 07 7月, 2010 4 次提交
  17. 12 6月, 2010 2 次提交
    • 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
    • R
      ACPI / ACPICA: Use helper function for computing GPE masks · e4e9a735
      Rafael J. Wysocki 提交于
      In quite a few places ACPICA needs to compute a GPE enable mask with
      only one bit, corresponding to a given GPE, set.  Currently, that
      computation is always open coded which leads to unnecessary code
      duplication.  Fix this by introducing a helper function for computing
      one-bit GPE enable masks and using it where appropriate.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e4e9a735
  18. 06 5月, 2010 1 次提交
  19. 20 4月, 2010 2 次提交
  20. 23 3月, 2010 1 次提交
    • R
      ACPI / ACPICA: Do not check reference counters in acpi_ev_enable_gpe() · bf02bd25
      Rafael J. Wysocki 提交于
      acpi_ev_enable_gpe() should enable the GPE at the hardware level
      regardless of the value of the GPE's runtime reference counter.
      
      There are only two callers of acpi_ev_enable_gpe(), acpi_enable_gpe()
      and acpi_set_gpe().  The first one checks the GPE's runtime
      reference counter itself and only calls acpi_ev_enable_gpe() if it's
      equal to one, and the other one is supposed to enable the GPE
      unconditionally (if called with ACPI_GPE_ENABLE).
      
      This change fixes the problem in acpi_enable_wakeup_device() where
      the GPE will not be enabled for wakeup if it's runtime reference
      counter is zero, which is a regression from 2.6.33.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: NRobert Moore <robert.moore@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      bf02bd25
  21. 25 2月, 2010 1 次提交
    • R
      ACPI: Use GPE reference counting to support shared GPEs · cbbc0de7
      Rafael J. Wysocki 提交于
      To fix a bug and address the reviewers' comments regarding the ACPI
      GPE refcounting patch, do the following additional changes:
      
      o Remove the second argument of acpi_ev_enable_gpe(),
        'write_to_hardware', because it is not necessary any more.
      
      o Add the "bad parameter" test against 'type' in
        acpi_enable_gpe() and acpi_disable_gpe().
      
      o Make acpi_enable_gpe() only check 'status' for runtime GPEs if
        acpi_ev_enable_gpe() was actually called.
      
      o Make acpi_disable_gpe() return 'status' returned by
        acpi_ev_disable_gpe() and fix a bug where ACPI_GPE_TYPE_WAKE
        and ACPI_GPE_TYPE_RUNTIME were exchanged by mistake.
      
      o Add comments explaining why acpi_set_gpe() is used by the ACPI EC
        driver.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      cbbc0de7
  22. 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
  23. 23 1月, 2010 1 次提交
  24. 27 8月, 2009 1 次提交
  25. 28 3月, 2009 1 次提交
  26. 09 1月, 2009 1 次提交