Add new GPE public interface - AcpiMarkGpeForWake.

Some potential callers of AcpiSetupGpeForWake may know in advance that
there won't be any notify handlers installed for device wake notifications
from the given GPE (one example is a button GPE in Linux). For these cases,
AcpiMarkGpeForWake should be used instead of AcpiSetupGpeForWake.
This will set the ACPI_GPE_CAN_WAKE flag for the GPE without trying to
setup implicit wake notification for it (since there's no handler method).
Rafael Wysocki.
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.

The OriginallyEnabled check is not paired between AcpiInstallGpeHandler()
and AcpiRemoveGpeHandler(). Lv Zheng.

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