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: Add unconditional GPE enabling support.

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: Remove AcpiEvEnableGpe().

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: Add reference counting for ACPI_GPE_HANDLER_INFO.

In order to allow GPE APIs to be invoked inside of GPE handler, 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 inside of the GPE handler. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix a divergence 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>