Events: Fix edge-triggered GPE by disabling before acknowledging it.

Due to ACPI specificiation 5, chapter 5.6.4 General-Purpose Event Hnadling,
OSPMs need to disable GPE before clearing the status bit for edge-triggered
GPEs. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that AcpiSetGpe() cannot unconditionally enable GPEs.

This patch adds unconditional GPE enabling support into AcpiSetGpe().

Originally this function checks if the GPE has been enabled with handlers
and performs acknowledging before enabling it.

First, IRQ enabling/disabling has 2 use cases:
1. When upper layers (the users of the driver) submit requests to the
   drivers, it means they care about the underlying hardware. For this
   case, AcpiEnableGpe() should be invoked. When the reference count is
   increased from 0 to 1, driver enables the hardware IRQ. And
   AcpiDisableGpe() is used as the reversal when the users have completed
   the submitted requests.
2. Driver may temporarily disables the IRQ and wants to re-enable it later,
   this case is normally used in order to prevent IRQ storm. When a driver
   cannot fully solve the condition that triggered the IRQ in the IRQ
   context, in order not to trigger IRQ storm, driver has to disable IRQ
   and re-enables it in the defered execution environment - which should be
   in a task context. This API should be used exactly for this purpose.

Second, since the AcpiSetGpe() should be invoked from an IRQ handler, the
handler check is useless for this API.

Third, 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 AcpiSetGpe(ACPI_GPE_ENABLE)
should not be implemented by AcpiHwLowSetGpe(ACPI_GPE_CONDITIONAL_ENABLE).

Fourth, GPE clearing is used to acknowledge the GPE. The combination of
acknowledging and enabling may not be expected by the hardware drivers. For
GPE clearing, we have a seperate API AcpiClearGpe(). There are cases
drivers do want the 2 operations to be split. For example, a high IO
throughput IRQ requires the IRQ to be cleared in the IRQ context. In order
to avoid GPE storm, same driver need to invoke IRQ re-enabling in the task
context. So splitting these 2 operations could facilitates drivers the
maximum possibilities to achieve success. For a combined one, we already
have AcpiFinishGpe() ready to be invoked.

This patch converts AcpiSetGpe(ACPI_GPE_ENABLE) into
AcpiHwLowSetGpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API.
Drivers are encouraged to use this API when they need to handle the above
mentioned cases. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that status of GPEs are unexpectedly cleared.

The stale GPE indication is not a problem. Drivers should always check the
underlying hardware status and be ready to handle invalid status.

The GPE clearing implemented in AcpiEvEnableGpe() on the contrary
introduces issues for AcpiEnableGpe() logic. When the usage count of GPE is
increased by suspend/resume code, GPE status shouldn't be cleared, or a GPE
loss could happen when the driver relies on the interrupt mode.

With previous cleanup, all AcpiEvEnableGpe() usages are removed, this patch
also removes this internal API. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that GPE APIs cannot be invoked in atomic context.

The GPE APIs should be invoked inside of an IRQ context GPE handler or in
the task context with a driver provided lock held. This driver provided
lock should be safe to be held in the GPE handler by the driver.

While currently we cannot do this, thus we can only use the GPE APIs for
limitted cases.

This patch adds reference counting for ACPI_GPE_HANDLER_INFO. Then the GPE
handler can be safely invoked without holding the GPE lock, thus
facilitates GPE APIs to be invoked in any atomic environment. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that GPE APIs cannot be invoked in deferred handlers.

The AcpiOsWaitEventsComplete() is used for flushing the deferred executed
handlers, invoking it for GPE interrupt handlers doesn't help to protect
GPE handler callback.  On the contrary, it prevents GPE APIs from being
invoked in the deferred notify handlers.

Actually, the GPE interrupt handlers' invocation is protected by the
previous implemented reference counting mechanism.

This patch fixes this GPE APIs invocation issue in a seperate commit other
than the reference counting one, so that if any regressions are reported,
this patch can be temporarily reverted before the regressions are root
caused. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that OriginallyEnabled check is not paired.

This is from Linux upstream. The OriginallyEnabled check is not paired
between AcpiInstallGpeHandler() and AcpiRemoveGpeHandler(). Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Add a flag to disable internal auto GPE clearing.

Clearing the status bit means OSPM acknowledges the GPE and the hardware
then can bring follow-up events up. Acklowdging it too early causes OSPM
seeing level triggered GPE storms or missing edge-triggered GPEs if the
OSPM driver responds slowly. Some drivers may choose to implement GPE
condition clearing code in a position that is different from where it
should be disabled or re-enabled, in which case, the internal auto GPE
clearing operations should be abandoned.

This flag facilitates such driver designs and implementations.

Note that drivers will need to invoke AcpiClearGpe() manually in a proper
position where the causes and conditions of the GPE have been solved and
the GPE status can be safely cleared. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>