[PATCH 0/9] ACPI/EC: Improve GPE handling model.

[Lv Zheng]

This patchset is based on the previous ACPI/EC bug fixes series.

This patchset has fixed the following issues:
1. Enables the ideal GPE handling model.
   The ideal GPE handling model should be able to handle the following
   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, acpi_enable_gpe() should be invoked. When the reference count
      is increased from 0 to 1, driver enables the hardware IRQ. And
      acpi_disable_gpe() 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 deferred execution environment
      - which should be in a task context. The acpi_set_gpe() API should be
      used exactly for this purpose.
   The reason why this model hasn't been enabled for the current Linux ACPI
   drivers is:
     In ACPICA, the same GPE lock is held while invoking the GPE handler
     callback, it's thus impossible to invoke GPE APIs in the GPE handler
     because the APIs requires to hold the GPE lock. The recursive locking
     leads to dead locks. This is a simple design defect, callbacks should
     always be invoked in a lockless environment, normally in Linux, this
     is achieved by RCU locking, and in ACPICA, we achieve this using
     reference counting.
   After fixing the above bug and doing necessary cleanups in the ACPICA
   GPE handling code, we now can enable this ideal GPE handling model for
   the EC driver to use.
2. Enables the EC commands flushing.
   This is quite important for ACPI platforms. Some EC driven ACPI devices
   may require all submitted EC commands to be completed before they can
   be safely suspended or unplugged. Otherwise the state of such devices
   will be broken.
   When implementing IO flushing, there always need to be 2 flags to
   indicate an intermediate state - old IO submissions observe the
   (STARTED) flag to continue; new IO submissions observe the (STOPPED)
   flag to be discarded. After introducing the 2 flags, a "stop waiter"
   is implemented for the suspending/removing operations of the EC driver.

The refined patches are passed the runtime/suspend tests carried out on the
following platforms:
  "Dell Inspiron Mini 1010" - i386 kernel
  "Dell Latitude 6430u" - x86_64 kernel
In this patchset, a unit test facility is also implemented. Test results
show that the GPE APIs and EC GPE model are now safe for hotplug support.

Lv Zheng (9):
  ACPICA: Events: Reduce indent divergences of events files.
  ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in
    atomic context.
  ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce
    divergences.
  ACPICA: Events: Remove acpi_ev_enable_gpe().
  ACPICA: Events: Reduce divergences to honor notify handler enabled
    GPEs.
  ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag.
  ACPI/EC: Add detailed command/query debugging information.
  ACPI/EC: Deploy the new GPE handling model.
  ACPI/EC: Add unit test support for EC driver hotplug.

 drivers/acpi/acpica/acevents.h |    1 +
 drivers/acpi/acpica/aclocal.h  |    5 +-
 drivers/acpi/acpica/evgpe.c    |  130 ++++++++++++++++--------------
 drivers/acpi/acpica/evxface.c  |   41 +++++++---
 drivers/acpi/acpica/evxfgpe.c  |  105 ++++++++++++++++++++++++
 drivers/acpi/ec.c              |  174 +++++++++++++++++++++++++++++++++-------
 6 files changed, 350 insertions(+), 106 deletions(-)

-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/