Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 22 5月, 2015 4 次提交
  3. 13 5月, 2015 1 次提交
  5. 15 4月, 2015 1 次提交
    • R
      ACPICA: Store GPE register enable masks upfront · 0ee0d349
      由 Rafael J. Wysocki 提交于 
      It is reported that ACPI interrupts do not work any more on
Dell Latitude D600 after commit c50f13c6 (ACPICA: Save
current masks of enabled GPEs after enable register writes).
The problem turns out to be related to the fact that the
enable_mask and enable_for_run GPE bit masks are not in
sync (in the absence of any system suspend/resume events)
for at least one GPE register on that machine.

Address this problem by writing the enable_for_run mask into
enable_mask as soon as enable_for_run is updated instead of
doing that only after the subsequent register write has
succeeded.  For consistency, update acpi_hw_gpe_enable_write()
to store the bit mask to be written into the GPE register
in enable_mask unconditionally before the write.

Since the ACPI_GPE_SAVE_MASK flag is not necessary any more after
that, drop it along with the symbols depending on it.
Reported-and-tested-by: NJim Bos <jim876@xs4all.nl>
Fixes: c50f13c6 (ACPICA: Save current masks of enabled GPEs after enable register writes)
Cc: 3.19+ <stable@vger.kernel.org> # 3.19+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0ee0d349
  7. 14 4月, 2015 24 次提交
  9. 13 2月, 2015 1 次提交
  11. 05 2月, 2015 9 次提交
    • L
      ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model · 2eedd3d8
      由 Lv Zheng 提交于 
      ACPICA commit da9a83e1a845f2d7332bdbc0632466b2595e5424

For acpi_set_gpe()/acpi_enable_gpe(), our target is to purify them to be APIs
that can be used for various GPE handling models, so we need them to be
pure GPE enabling APIs. GPE enabling/disabling has 2 use cases:
1. Driver may permanently enable/disable GPEs according to the usage
   counts.
   1. When upper layers (the users of the driver) submit requests to the
      driver, it means they care about the underlying hardware. GPE need
      to be enabled for the first request submission and disabled for the
      last request completion.
   2. When the GPE is shared between 2+ silicon logics. GPE need to be
      enabled for either silicon logic's driver and disabled when all of
      the drivers are not started.
   For these cases, acpi_enable_gpe()/acpi_disable_gpe() should be used. When
   the usage count is increased from 0 to 1, the GPE is enabled and it is
   disabled when the usage count is decrased from 1 to 0.
2. Driver may temporarily disables the GPE to enter an GPE polling mode and
   wants to re-enable it later.
   1. Prevent GPE storming: when a driver cannot fully solve the condition
      that triggered the GPE in the GPE context, in order not to trigger
      GPE storm, driver has to disable GPE to switch into the polling mode
      and re-enables it in the non interrupt context after the storming
      condition is cleared.
   2. Meet throughput requirement: some IO drivers need to poll hardware
      again and again until nothing indicated instead of just handling once
      for one interruption, this need to be done in the polling mode or the
      IO flood may prevent the GPE handler from returning.
   3. Meet realtime requirement: in order not to block CPU to handle higher
      realtime prioritized GPEs, lower priority GPEs can be handled in the
      polling mode.
   For these cases, acpi_set_gpe() should be used to switch to/from the
   polling mode.

This patch adds unconditional GPE enabling support into acpi_set_gpe() so
that this API can be used by the drivers to switch back from the GPE
polling mode unconditionally.

Originally this function includes GPE clearing logic in it.
First, the GPE clearing is typically used in the GPE handling code to:
1. Acknowledge the GPE when we know there is an edge triggered GPE raised
   and is about to handle it, otherwise the unexpected clearing may lead to
   a GPE loss;
2. Issue actions after we have handled a level triggered GPE, otherwise
   the unexpected clearing may trigger unwanted OSPM actions to the
   hardware (for example, clocking in out-dated write FIFO data).
Thus the GPE clearing is not suitable to be used in the GPE enabling APIs.
Second, the combination of acknowledging and enabling may also not be
expected by the hardware drivers. For GPE clearing, we have a seperate API
acpi_clear_gpe(). There are cases drivers do want the 2 operations to be
split. So splitting these 2 operations could facilitates drivers the
maximum possibilities to achieve success. For a combined one, we already
have acpi_finish_gpe() ready to be invoked.

Given the fact that drivers should complete all outstanding requests before
putting themselves into the sleep states, as this API is executed for
outstanding requests, it should also have nothing to do with the
"RUN"/"WAKE" distinguishing. That's why the acpi_set_gpe(ACPI_GPE_ENABLE)
should not be implemented by acpi_hw_low_set_gpe(ACPI_GPE_CONDITIONAL_ENABLE).

This patch thus converts acpi_set_gpe(ACPI_GPE_ENABLE) into
acpi_hw_low_set_gpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API.
Drivers then are encouraged to use this API when they need to switch
to/from the GPE polling mode.

Note that the acpi_set_gpe()/acpi_finish_gpe() should be first introduced to
Linux using a divergence reduction patch before sending a linuxized version
of this patch. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/da9a83e1Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2eedd3d8
    • L
      ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences · eb3d80f7
      由 Lv Zheng 提交于 
      This can help to reduce source code differences between Linux and ACPICA
upstream. Further driver cleanups also require these APIs to eliminate GPE
storms.
1. acpi_set_gpe(): An API that driver should invoke in the case it wants
                   to disable/enable IRQ without honoring the reference
                   count implemented in the acpi_disable_gpe() and
                   acpi_enable_gpe(). Note that this API should only be
                   invoked inside a acpi_enable_gpe()/acpi_disable_gpe()
                   pair.
2. acpi_finish_gpe(): Drivers returned ACPI_REENABLE_GPE unset from the
                      GPE handler should use this API instead of
                      invoking acpi_set_gpe()/acpi_enable_gpe() to
                      re-enable the GPE.
The GPE APIs can be invoked inside of a GPE handler or in the task context
with a driver provided lock held. This driver provided lock is safe to be
held in the GPE handler by the driver.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eb3d80f7
    • L
      ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs · 0d0988af
      由 Lv Zheng 提交于 
      ACPICA commit 199cad16530a45aea2bec98e528866e20c5927e1

Since whether the GPE should be disabled/enabled/cleared should only be
determined by the GPE driver's state machine:
1. GPE should be disabled if the driver wants to switch to the GPE polling
   mode when a GPE storm condition is indicated and should be enabled if
   the driver wants to switch back to the GPE interrupt mode when all of
   the storm conditions are cleared. The conditions should be protected by
   the driver's specific lock.
2. GPE should be enabled if the driver has accepted more than one request
   and should be disabled if the driver has completed all of the requests.
   The request count should be protected by the driver's specific lock.
3. GPE should be cleared either when the driver is about to handle an edge
   triggered GPE or when the driver has completed to handle a level
   triggered GPE. The handling code should be protected by the driver's
   specific lock.
Thus the GPE enabling/disabling/clearing operations are likely to be
performed with the driver's specific lock held while we currently cannot do
this. This is because:
1. We have the acpi_gbl_gpe_lock held before invoking the GPE driver's
   handler. Driver's specific lock is likely to be held inside of the
   handler, thus we can see some dead lock issues due to the reversed
   locking order or recursive locking. In order to solve such dead lock
   issues, we need to unlock the acpi_gbl_gpe_lock before invoking the
   handler. BZ 1100.
2. Since GPE disabling/enabling/clearing should be determined by the GPE
   driver's state machine, we shouldn't perform such operations inside of
   ACPICA for a GPE handler to mess up the driver's state machine. BZ 1101.

Originally this patch includes a logic to flush GPE handlers, it is dropped
due to the following reasons:
1. This is a different issue;
2. Linux OSL has fixed this by flushing SCI in acpi_os_wait_events_complete().
We will pick up this topic when the Linux OSL fix turns out to be not
sufficient.

Note that currently the internal operations and the acpi_gbl_gpe_lock are
also used by ACPI_GPE_DISPATCH_METHOD and ACPI_GPE_DISPATCH_NOTIFY. In
order not to introduce regressions, we add one
ACPI_GPE_DISPATCH_RAW_HANDLER type to be distiguished from
ACPI_GPE_DISPATCH_HANDLER. For which the acpi_gbl_gpe_lock is unlocked before
invoking the GPE handler and the internal enabling/disabling operations are
bypassed to allow drivers to perform them at a proper position using the
GPE APIs and ACPI_GPE_DISPATCH_RAW_HANDLER users should invoke acpi_set_gpe()
instead of acpi_enable_gpe()/acpi_disable_gpe() to bypass the internal GPE
clearing code in acpi_enable_gpe(). Lv Zheng.

Known issues:
1. Edge-triggered GPE lost for frequent enablings
   On some buggy silicon platforms, GPE enable line may not be directly
   wired to the GPE trigger line. In that case, when GPE enabling is
   frequently performed for edge-triggered GPEs, GPE status may stay set
   without being triggered.
   This patch may maginify this problem as it allows GPE enabling to be
   parallel performed during the process the GPEs are handled.
   This is an existing issue, because:
   1. For task context:
      Current ACPI_GPE_DISPATCH_METHOD practices have proven that this
      isn't a real issue - we can re-enable edge-triggered GPE in a work
      queue where the GPE status bit might already be set.
   2. For IRQ context:
      This can even happen when the GPE enabling occurs before returning
      from the GPE handler and after unlocking the GPE lock.
   Thus currently no code is included to protect this.

Link: https://github.com/acpica/acpica/commit/199cad16Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0d0988af
    • D
      ACPICA: Update Copyright headers to 2015 · 82a80941
      由 David E. Box 提交于 
      ACPICA commit 8990e73ab2aa15d6a0068b860ab54feff25bee36

Link: https://github.com/acpica/acpica/commit/8990e73aSigned-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      82a80941
    • D
      ACPICA: Hardware: Cast GPE enable_mask before storing · d6c02669
      由 David E. Box 提交于 
      ACPICA commit 490ec7f7839bf7ee5e8710a34d1d1a78d54a49b6

In function acpi_hw_low_set_gpe(), cast enable_mask to u8 before
storing. The mask was read from a 32 bit register but is an 8 bit
value. Fixes Visual Studio compiler warning.

Link: https://github.com/acpica/acpica/commit/490ec7f7Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d6c02669
    • L
      ACPICA: Events: Cleanup GPE dispatcher type obtaining code · 7c43312a
      由 Lv Zheng 提交于 
      ACPICA commit 7926d5ca9452c87f866938dcea8f12e1efb58f89

There is an issue in acpi_install_gpe_handler() and acpi_remove_gpe_handler().
The code to obtain the GPE dispatcher type from the Handler->original_flags
is wrong:
    if (((Handler->original_flags & ACPI_GPE_DISPATCH_METHOD) ||
         (Handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) &&
ACPI_GPE_DISPATCH_NOTIFY is 0x03 and ACPI_GPE_DISPATCH_METHOD is 0x02, thus
this statement is TRUE for the following dispatcher types:
    0x01 (ACPI_GPE_DISPATCH_HANDLER): not expected
    0x02 (ACPI_GPE_DISPATCH_METHOD): expected
    0x03 (ACPI_GPE_DISPATCH_NOTIFY): expected

There is no functional issue due to this because Handler->original_flags is
only set in acpi_install_gpe_handler(), and an earlier checker has excluded
the ACPI_GPE_DISPATCH_HANDLER:
    if ((gpe_event_info->Flags & ACPI_GPE_DISPATCH_MASK) ==
            ACPI_GPE_DISPATCH_HANDLER)
    {
        Status = AE_ALREADY_EXISTS;
        goto free_and_exit;
    }
    ...
    Handler->original_flags = (u8) (gpe_event_info->Flags &
        (ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK));

We need to clean this up before modifying the GPE dispatcher type values.

In order to prevent such issue from happening in the future, this patch
introduces ACPI_GPE_DISPATCH_TYPE() macro to be used to obtain the GPE
dispatcher types. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/7926d5caSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7c43312a
    • L
      ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out... · 779ba5a3
      由 Lv Zheng 提交于 
      ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out of acpi_ev_gpe_dispatch()

ACPICA commit 04f25acdd4f655ae33f83de789bb5f4b7790171c

This patch follows acpi_ev_fixed_event_detect(), which invokes
acpi_gbl_global_event_handler instead of invoking it in
acpi_ev_fixed_event_dispatch(), moves acpi_gbl_global_event_handler from
acpi_ev_gpe_dispatch() to acpi_ev_gpe_detect(). This makes further cleanups
around acpi_ev_gpe_dispatch() simpler. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/04f25acdSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      779ba5a3
    • L
      ACPICA: Events: Cleanup of resetting the GPE handler to NULL before removing · c539251e
      由 Lv Zheng 提交于 
      ACPICA commit b2b18bb38045404e253f10787b8a4ae6e94cdee6

This patch prevents acpi_remove_gpe_handler() from leaking the stale
gpe_event_info->Dispatch.Handler to the caller to avoid possible NULL pointer
references. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/b2b18bb3Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c539251e
    • D
      ACPICA: Events: Fix uninitialized variable · b7be6883
      由 David E. Box 提交于 
      ACPICA commit 8e21180050270897499652e922c6a41b8eb388b6

Recent changes to acpi_ev_asynch_execute_gpe_method left Status
variable uninitialized before use. Initialize to AE_OK.

Link: https://github.com/acpica/acpica/commit/8e211800Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b7be6883