[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1659923.7L0Vy69Ets@vostro.rjw.lan>
Date: Tue, 15 Jul 2014 14:25:33 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Lv Zheng <lv.zheng@...el.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Len Brown <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v2 0/9] ACPICA: Improve GPE handling model.
On Tuesday, July 15, 2014 11:07:10 AM Lv Zheng wrote:
> This patchset 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 require 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 implement "commands flushing" and "storm prevention" (the EC
> driver enabling is not included in this patchset).
How this patch series is related to upstream ACPICA? Is the design fixed
already upstream?
> The refined patches are passed the runtime/suspend tests carried out on the
> following platforms with EC driver enhanced:
> "Dell Inspiron Mini 1010" - i386 kernel
> "Dell Latitude 6430u" - x86_64 kernel
>
> 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: Fix an issue that GPE APIs cannot be invoked in
> deferred handlers.
> ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce
> divergences.
> ACPICA: Events: Fix an issue that acpi_set_gpe() cannot
> unconditionally enable GPEs.
> ACPICA: Events: Fix an issue that status of GPEs are unexpectedly
> cleared.
> ACPICA: Events: Fix an issue that originally_enabled check is not
> paired.
> ACPICA: Events: Add a flag to disable internal auto GPE clearing.
> ACPI: Update interrupt handler to honor new ACPI_REENABLE_GPE bit.
>
> drivers/acpi/acpica/acevents.h | 1 +
> drivers/acpi/acpica/aclocal.h | 5 +-
> drivers/acpi/acpica/evgpe.c | 136 +++++++++++++++++++++-------------------
> drivers/acpi/acpica/evxface.c | 41 ++++++++----
> drivers/acpi/acpica/evxfgpe.c | 105 +++++++++++++++++++++++++++++++
> drivers/acpi/osl.c | 2 +-
> include/acpi/actypes.h | 16 ++---
> 7 files changed, 219 insertions(+), 87 deletions(-)
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists