1. 25 1月, 2013 1 次提交
  2. 10 1月, 2013 2 次提交
    • L
      ACPICA: Cleanup indentation to reduce differences between Linux and ACPICA. · 3e8214e5
      Lv Zheng 提交于
      This is a cosmetic patch only. Comparison of the resulting binary showed
      only line number differences.
      
      This patch does not affect the generation of the Linux binary.
      This patch decreases 210 lines of 20121018 divergence.diff.
      
      The ACPICA source codes uses a totally different indentation style from the
      Linux to be compatible with other users (operating systems or BIOS).
      
      Indentation differences are critical to the release automation. There are
      two causes related to the "indentation" that are affecting the release
      automation:
      1. The ACPICA -> Linux release process is:
           ACPICA source -- acpisrc - hierarchy - indent ->
           linuxized ACPICA source -- diff ->
           linuxized ACPICA patch (x) -- human intervention ->
           linuxized ACPICA patch (o)
           Where
             'x' means "cannot be directly applied to the Linux"
             'o' means "can be directly applied to the Linux"
         Different "indent" version or "indent" options used in the "indent"
         step will lead to different divergences.
         The version of "indent" used for the current release process is:
           GNU indent 2.2.11
         The options of "indent" used for the current release process is:
           -npro -kr -i8 -ts8 -sob -l80 -ss -ncs
      2. Manual indentation prettifying work in the Linux side will also harm the
         automatically generated linuxized ACPICA patches, making them impossible
         to apply directly.
      
      This patch fixes source code differences caused by the two causes so that
      the "human intervention" can be reduced in the future.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3e8214e5
    • L
      ACPICA: Cleanup updated comments. · 75c8044f
      Lv Zheng 提交于
      This is a cosmetic patch only. Comparison of the resulting binary showed
      only line number differences.
      
      This patch does not affect the generation of the Linux binary.
      This patch decreases 558 lines of 20121018 divergence.diff.
      
      This patch reduces the source code diff between Linux and ACPICA by
      cleaning the comments that already have been updated in ACPICA.
      
      There is no extra indentation done in this patch. Even the empty line
      deletions and insertions are also splitted into another cleanup patch so
      that this patch can be easily reviewed, and the binary differences can be
      held to a lowest level.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      75c8044f
  3. 17 7月, 2012 1 次提交
  4. 22 3月, 2012 1 次提交
  5. 17 1月, 2012 1 次提交
  6. 01 11月, 2011 1 次提交
  7. 19 1月, 2011 1 次提交
  8. 12 1月, 2011 1 次提交
  9. 25 9月, 2010 1 次提交
    • R
      ACPI / ACPICA: Defer enabling of runtime GPEs (v3) · a2100801
      Rafael J. Wysocki 提交于
      The current ACPI GPEs initialization code has a problem that it
      enables some GPEs pointed to by device _PRW methods, generally
      intended for signaling wakeup events (system or device wakeup).
      These GPEs are then almost immediately disabled by the ACPI namespace
      scanning code with the help of acpi_gpe_can_wake(), but it would be
      better not to enable them at all until really necessary.
      
      Modify the initialization of GPEs so that the ones that have
      associated _Lxx or _Exx methods and are not pointed to by any _PRW
      methods will be enabled after the namespace scan is complete.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a2100801
  10. 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
  11. 13 7月, 2010 2 次提交
    • R
      ACPI / ACPICA: Fail acpi_gpe_wakeup() if ACPI_GPE_CAN_WAKE is unset · 9ce10df8
      Rafael J. Wysocki 提交于
      Make acpi_gpe_wakeup() return error code for GPEs whose
      ACPI_GPE_CAN_WAKE flag is not set.  This way acpi_gpe_wakeup() will
      only wake for the GPEs reported by the host OS as "wakeup" ones with
      the help of acpi_gpe_can_wake().
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      9ce10df8
    • R
      ACPI / ACPICA: Do not execute _PRW methods during initialization · 9874647b
      Rafael J. Wysocki 提交于
      Currently, during initialization ACPICA walks the entire ACPI
      namespace in search of any device objects with assciated _PRW
      methods.  All of the _PRW methods found are executed in the process
      to extract the GPE information returned by them, so that the GPEs in
      question can be marked as "able to wakeup" (more precisely, the
      ACPI_GPE_CAN_WAKE flag is set for them).  The only purpose of this
      exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
      if there are _Lxx/_Exx methods associated with them.  However, it is
      both costly and unnecessary, because the host OS has to execute the
      _PRW methods anyway to check which devices can wake up the system
      from sleep states.  Moreover, it then uses full information
      returned by _PRW, including the GPE information, so it can take care
      of disabling the GPEs if necessary.
      
      Remove the code that walks the namespace and executes _PRW from
      ACPICA and modify comments to reflect that change.  Make
      acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
      so that they don't cause spurious wakeup events to be signaled.
      This not only reduces the complexity of the ACPICA initialization
      code, but in some cases it should reduce the kernel boot time as
      well.
      
      Unfortunately, for this purpose we need a new ACPICA function,
      acpi_gpe_can_wake(), to be called by the host OS in order to disable
      the GPEs that can wake up the system and were previously enabled by
      acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
      should be disabled only once, because the initialization code enables
      it only once, but it may be pointed to by _PRW for multiple devices
      and that's why the additional function is necessary).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      9874647b
  12. 07 7月, 2010 4 次提交
    • R
      ACPICA: Drop acpi_set_gpe · 546eb576
      Rafael J. Wysocki 提交于
      The acpi_set_gpe() function is a little awkward, because it doesn't
      really work as advertised in the "disable" case.  Namely, if a GPE
      has been enabled with acpi_enable_gpe() and triggered a notification
      to occur, and if acpi_set_gpe() is used to disable it before
      acpi_ev_asynch_enable_gpe() runs, the GPE will be immediately enabled
      by the latter as though the acpi_set_gpe() had no effect.
      
      Thus, since it's been possible to make all of its callers use
      alternative operations to disable or enable GPEs, acpi_set_gpe() can
      be dropped.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      546eb576
    • R
      ACPICA: Use low-level GPE enable during GPE block initialization · 3bd741bd
      Rafael J. Wysocki 提交于
      The GPE block initialization code in acpi_ev_initialize_gpe_block()
      uses acpi_set_gpe() to make sure that the GPEs with nonzero
      runtime counter will remain enabled, but since it already has
      a struct acpi_gpe_event_info object for each GPE, it might use
      the low-level GPE enabling function, acpi_clear_and_enable_gpe(),
      for this purpose.
      
      To make that happen, move acpi_clear_and_enable_gpe() to
      drivers/acpi/acpica/evgpe.c and rename it to acpi_ev_enable_gpe(),
      modify the two existing users of it accordingly and modify
      acpi_ev_initialize_gpe_block() to use it instead of acpi_set_gpe()
      and to check its return value.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      3bd741bd
    • R
      ACPICA: Remove wakeup GPE reference counting which is not used · a44061aa
      Rafael J. Wysocki 提交于
      After the previous patch that introduced acpi_gpe_wakeup() and
      modified the ACPI suspend and wakeup code to use it, the third
      argument of acpi_{enable|disable}_gpe() and the GPE wakeup
      reference counter are not necessary any more.  Remove them and
      modify all of the users of acpi_{enable|disable}_gpe()
      accordingly.  Also drop GPE type constants that aren't used
      any more.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a44061aa
    • R
      ACPICA: Introduce acpi_gpe_wakeup() · e8b6f970
      Rafael J. Wysocki 提交于
      ACPICA uses reference counters to avoid disabling GPEs too early in
      case they have been enabled for many times.  This is done separately
      for runtime and for wakeup, but the wakeup GPE reference counter is
      not really necessary, because GPEs are only enabled to wake up the
      system at the hardware level by acpi_enter_sleep_state().  Thus it
      only is necessary to set the corresponding bits in the wakeup enable
      masks of these GPEs' registers right before the system enters a sleep
      state.  Moreover, the GPE wakeup enable bits can only be set when the
      target sleep state of the system is known and they need to be cleared
      immediately after wakeup regardless of how many wakeup devices are
      associated with a given GPE.
      
      On the basis of the above observations, introduce function
      acpi_gpe_wakeup() to be used for setting or clearing the enable bit
      corresponding to a given GPE in its enable register's enable_for_wake
      mask.  Modify the ACPI suspend and wakeup code the use
      acpi_gpe_wakeup() instead of acpi_{enable|disable}_gpe() to set
      and clear GPE enable bits in their registers' enable_for_wake masks
      during system transitions to a sleep state and back to the working
      state, respectively.  [This will allow us to drop the third
      argument of acpi_{enable|disable}_gpe() and simplify the GPE
      handling code.]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e8b6f970
  13. 29 6月, 2010 1 次提交
  14. 12 6月, 2010 1 次提交
    • 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
  15. 12 5月, 2010 1 次提交
    • L
      ACPICA: simplify SCI_EN workaround · b430acbd
      Len Brown 提交于
      acpi_hw_set_mode() double checks its effectiveness
      by calling acpi_hw_get_mode() -- polling up to 3 seconds.
      
      It would be more logical for its caller, acpi_enable()
      acpi_enable() to do the double-checking.  (lets assume
      that acpi_disable() isn't interesting)
      
      The ACPI specification is unclear on this point.
      Some parts say that the BIOS sets SCI_EN and then returns to the OS,
      but one part says "OSPM polls the SCI_EN bit until it is sampled SET".
      
      The systems I have on hand do the former,
      SCI_EN is observed to be set upon return from the BIOS.
      
      So we move the check up out of acpi_hw_set_mode()
      up into acpi_enable() where it makes logical sense.
      
      Then we replace the 3-second polling loop
      with a single check.  If this check fails, we'll see:
      
      	"Hardware did not enter ACPI mode"
      
      and the system will bail out of ACPI initialization
      and likely fail to boot.  If we see that in practice,
      we can restore the polling, but put it into acpi_enable.
      
      This patch is important if acpi_enable() is used in
      the resume from S3 path.  Many systems today are seen
      coming back from S3 with SCI_EN off, and then failing
      to set SCI_EN in response to acpi_enable().  Those systems
      will take 3 seconds longer to resume due to this loop.
      
      However, it is possible that we will not use acpi_enable()
      in the S3 resume path, and bang SCI_EN directly, which
      would make the loop harmless, as it would be invisible
      to all systems except those that need it.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b430acbd
  16. 20 4月, 2010 1 次提交
  17. 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
  18. 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
  19. 23 1月, 2010 1 次提交
  20. 16 12月, 2009 1 次提交
  21. 27 5月, 2009 1 次提交
  22. 28 3月, 2009 1 次提交
  23. 27 3月, 2009 1 次提交
  24. 09 1月, 2009 2 次提交
  25. 31 12月, 2008 3 次提交
  26. 30 12月, 2008 1 次提交
  27. 12 11月, 2008 1 次提交
  28. 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
  29. 17 7月, 2008 1 次提交
  30. 24 4月, 2008 1 次提交
  31. 10 5月, 2007 1 次提交
  32. 03 2月, 2007 1 次提交