ACPI 5.1: Support for the _DSD predefined name.

Adds full support for _DSD. David Box.
ACPI 5.1: New notify value for System Affinity Update.

New value for the Notify() operator.
ACPI 5.1: Support for the _CCA predifined name.

Full support for _CCA.
ACPI 5.1: Update for FADT changes.

Adds ARM flags and FADT minor revision. Graeme Gregory.
graeme.gregory@linaro.org
ACPI 5.1: Update for MADT changes.

New subtables and changes to other subtables. Tomasz Nowicki.
tomasz.nowicki@linaro.org
ACPI 5.1: Update for GTDT table changes.

New fields and new subtables. Tomasz Nowicki.
tomasz.nowicki@linaro.org
ACPI 5.1: Update iASL supported ACPI revision to 5.1

Emitted for compiler signon.
ACPI 5.1: Update AcpiSrc for new structures.

New structures in the ACPI table headers.
ACPI 5.1: Update for PCCT table changes.

One new subtable.
ACPICA reference: Add new GPE interface.

For version 20140724.
Logfile: Changes for version 20140724.

Version 20140724.
Update version to 20140724.

Version 20140724.
Linuxize: Add upstream commit ID in the generated patches.

This patch adds support to add ACPICA upstream Commit ID/Author in the
generated linuxized patches. This format follows Linux stable material
format. The modifications include:
1. distiguish COMMITTER, AUTHOR, MAINTAINER:
   1. COMMITTER is automatically extracted using "git config --get";
   2. AUTHOR is automatically extracted using "git log --format=%aN <%aE>";
   3. MAINTAINER is fixed in make-patches.sh, currently it is
      "Bob Moore <robert.moore@intel.com>".
2. add AUTHOR and COMMIT ID information to form the ACPICA release patch
   header.
3. automatically correct "Robert Moore <Robert.Moore@intel.com>" to
   "Bob Moore <bob.moore@intel.com>".
4. automatically remove last empty lines in the patch description.
5. automatically append unique Signed-off-by for AUTHOR, NAINTAINER and
   COMMITTER.
6. automatically add commit URL before SOBs and add "-l" option to be ready
   for changing the host of the repo.
The generated patch format is ACKed by the Linux ACPI maintainer. Lv Zheng.

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

AcpiEvEnableGpe() is invoked by:
1. AcpiSetGpe()
2. AcpiEnableGpe()
3. AcpiRemoveGpeHandler()
4. AcpiUpdateAllGpes
The AcpiRemoveGpeHandler() is a driver removal operation, AcpiEvEnableGpe()
invocation in it is used for the origianlly enabled GPEs, so we needn't
perform too many sanity checks for it.
For AcpiSetGpe()/AcpiEnableGpe(), our target is to purify them to be APIs
can be used for request based driver handling code, so we need them to be
pure GPE enabling APIs without the GPE clearing logic implemented in it.

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.

AcpiEvEnableGpe() is invoked by:
1. AcpiSetGpe()
2. AcpiEnableGpe()
3. AcpiRemoveGpeHandler()
4. AcpiUpdateAllGpes
The AcpiRemoveGpeHandler() is a driver removal operation, AcpiEvEnableGpe()
invocation in it is used for the origianlly enabled GPEs, so we needn't
perform too many sanity checks for it.
For AcpiSetGpe()/AcpiEnableGpe(), our target is to purify them to be APIs
can be used for request based driver handling code, so we need them to be
pure GPE enabling APIs without the GPE clearing logic implemented in it.

This patch checks the requirements for the logics implemented in the
original AcpiEnableGpe() that are conflict with our improvements.

1. For "stale events clearing":
The GPE clearing implemented in AcpiEvEnableGpe() introduces issues for
AcpiEnableGpe() logic: When the reference count of the GPE is increased by
the request based runtime PM capable driver code and the system PM
suspend/resume aware driver code, GPE status shouldn't be cleared, or a GPE
loss could happen when the driver relies on the interrupt mode. It is
expected that the GPE status clearing only happens in the IRQ handler to
fix this issue. So let's check the cases for the task context we may need
it before removing this logic:
1. By implementing state machine correctly, driver can clean the conditions
   that trigger such GPE status, some silicon logics may be able to clear
   the GPE status automatically after the conditions have been cleared, so
   the drivers are safe to poll the hardware without clearing the GPE
   status.
2. Even for the silicon logics that cannot clear the GPE status
   automatically, since the drivers should be ready for the shared IRQs,
   the drivers should have already implemented IRQ handlers to check the
   individual hardware condition bits. A GPE raised without any individual
   hardware condition bit indicated will only invoke the IRQ handler as a
   no-op. So the drivers are still safe to work in the polling mode without
   clearing the GPE status in the task context, it only adds 1 no-op IRQ
   handler invocation overhead, this IRQ handler invocation clears the
   status bit without doing anything else.
3. If there are arbitrary "stale events" (for example, silicon bugs) upon
   enabling the IRQ, the driver's IRQ handler should be able to detect and
   handle them as no-ops like the case 2. In such case, the no-op IRQ
   handler invocations will be more than once and the driver will still not
   be broken by switching between the IRQ mode and the polling mode. Note
   that such "stale events" will be treated as an IRQ storm triggered by
   the buggy silicons. Even for the IRQ only mode, the storms will remain
   there. So this should be handled by the storm prevention logics
   implemented in the driver.
4. As a conclusion, there should be no situation to peform "stale events
   clearing" out side of IRQ handler when the OSPM driver is ready. It
   might be required by AcpiUpdateAllGpes() to work around some firmware
   bugs during the OSPM booting period where the OSPM driver is not ready.
   Though correct _Lxx/_Exx should be capable of handling such events like
   the case 2, without knowing the real issues the AcpiUpdateAllGpes() is
   trying to handle (it might be _Lxx/_Exx bugs), in order not to trigger
   regressions, this patch keeps this logic only for this function.

2. For "dispatcher availability checks":
All checks are already done in
AcpiEnableGpe()/AcpiRemoveGpeHandler()/AcpiUpdateAllGpes() before invoking
AcpiEvEnableGpe(). For AcpiSetGpe(), since it is invoked by the OSPM driver
where the IRQ handler is known to be available, such check isn't needed. So
this patch can simply remove this check.

Along with the previous cleanups, by moving the "stale events clearing"
logic to AcpiEvInitializeGpeBlock() (which is invoked by
AcpiUpdateAllGpes()), all AcpiEvEnableGpe() usages are removed, this patch
can also remove this internal API by moving the unconditional enabling code
to AcpiEvAddGpeReference(). 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>
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 leve-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 and some silicon can implement special
GPE status as R1C (read once clear). For those 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>
Events: Add a flag to disable internal auto GPE disabling.

The ACPI specification around the GPE handling is talking about a threaded
IRQ model (which is also known as the IRQ polling mode comparing to the
interrupted IRQ mode). GPE is disabled in the IRQ context and re-enabled in
the IRQ polling thread (task context) after the interrupt has been
correctly handled.

For interrupted IRQ mode IRQ handler (ACPICA GPE dispatcher can only be
implemented in this mode), disabling IRQ is useless as IRQ is automatically
disabled before invoking the handler for the same CPU. There is no hardware
in the real world can trigger an IRQ on the same CPU to preempt the handler
of the same IRQ.

And the automatic IRQ disabling is harmful to request based low power IO
drivers where IRQ enabling/disabling is managed by the power references and
the storm conditions.
The IRQ disabling/enabling out of the drivers' control can mess up the IRQ
enabling state where:
1. Enabling IRQ means there is more than 1 requests and no storms;
2. Disabling IRQ means there is no request or there is a storm.

This patch adds a flag to control the ACPICA internal GPE disabling to
facilitate request based low power IO drivers to work in the GPE level.

Since we will have users for the new GPE flag to enable a runtime idle
style GPE driver, this patch also enables AcpiInstallGpeHandler() to
configure NO_AUTO_x flags. Lv Zheng.

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