* [PATCH] acpi: update return value in EC gpe handler
@ 2010-12-15 7:47 Lin Ming
2010-12-15 20:04 ` Moore, Robert
0 siblings, 1 reply; 3+ messages in thread
From: Lin Ming @ 2010-12-15 7:47 UTC (permalink / raw)
To: lenb; +Cc: Moore, Robert, Rafael J. Wysocki, linux-acpi
EC gpe handler should return ACPI_REENABLE_GPE, so acpi_ev_gpe_dispatch
can clear and reenable the GPE.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
Len,
I forgot to update EC gpe handler return value in the series of
"[PATCH v2 0/8] Minimize ACPICA/linux GPE code divergence".
This is the fix.
drivers/acpi/ec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index e15439a..8a0e907 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -619,7 +619,7 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
wake_up(&ec->wait);
ec_check_sci(ec, acpi_ec_read_status(ec));
}
- return ACPI_INTERRUPT_HANDLED;
+ return ACPI_REENABLE_GPE;
}
/* --------------------------------------------------------------------------
^ permalink raw reply related [flat|nested] 3+ messages in thread
* RE: [PATCH] acpi: update return value in EC gpe handler
2010-12-15 7:47 [PATCH] acpi: update return value in EC gpe handler Lin Ming
@ 2010-12-15 20:04 ` Moore, Robert
2010-12-17 22:17 ` Rafael J. Wysocki
0 siblings, 1 reply; 3+ messages in thread
From: Moore, Robert @ 2010-12-15 20:04 UTC (permalink / raw)
To: Lin, Ming M, lenb; +Cc: Rafael J. Wysocki, linux-acpi
I'm not sure that this is the correct thing to do.
ACPI_REENABLE_GPE is a new GPE handler return value that implies to ACPICA that the GPE has been fully handled within the (synchronous, interrupt-level) GPE handler and is ready to be cleared (if necessary) and re-enabled.
The acpi_finish_gpe is a new interface does the same thing, but is intended to be called from an asynchronous GPE handler after the GPE processing is completed. It looks to me that the EC GPE handler is mostly asynchronous, so I suspect that somewhere in the EC driver, a call to acpi_finish_gpe should replace a couple of calls to clear the GPE and re-enable it. That is the purpose of this interface, to relieve the handler of deciding whether to clear the GPE or not (level vs. edge) and then re-enabling it.
Bob
-----Original Message-----
From: Lin, Ming M
Sent: Tuesday, December 14, 2010 11:47 PM
To: lenb
Cc: Moore, Robert; Rafael J. Wysocki; linux-acpi
Subject: [PATCH] acpi: update return value in EC gpe handler
EC gpe handler should return ACPI_REENABLE_GPE, so acpi_ev_gpe_dispatch
can clear and reenable the GPE.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
Len,
I forgot to update EC gpe handler return value in the series of
"[PATCH v2 0/8] Minimize ACPICA/linux GPE code divergence".
This is the fix.
drivers/acpi/ec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index e15439a..8a0e907 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -619,7 +619,7 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
wake_up(&ec->wait);
ec_check_sci(ec, acpi_ec_read_status(ec));
}
- return ACPI_INTERRUPT_HANDLED;
+ return ACPI_REENABLE_GPE;
}
/* --------------------------------------------------------------------------
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] acpi: update return value in EC gpe handler
2010-12-15 20:04 ` Moore, Robert
@ 2010-12-17 22:17 ` Rafael J. Wysocki
0 siblings, 0 replies; 3+ messages in thread
From: Rafael J. Wysocki @ 2010-12-17 22:17 UTC (permalink / raw)
To: Moore, Robert; +Cc: Lin, Ming M, lenb, linux-acpi
On Wednesday, December 15, 2010, Moore, Robert wrote:
> I'm not sure that this is the correct thing to do.
>
> ACPI_REENABLE_GPE is a new GPE handler return value that implies to ACPICA that the GPE has been fully handled within the (synchronous, interrupt-level) GPE handler and is ready to be cleared (if necessary) and re-enabled.
>
> The acpi_finish_gpe is a new interface does the same thing, but is intended to be called from an asynchronous GPE handler after the GPE processing is completed. It looks to me that the EC GPE handler is mostly asynchronous, so I suspect that somewhere in the EC driver, a call to acpi_finish_gpe should replace a couple of calls to clear the GPE and re-enable it. That is the purpose of this interface, to relieve the handler of deciding whether to clear the GPE or not (level vs. edge) and then re-enabling it.
You're generally right, but that would involve a major rework of the EC driver,
while I think at the moment we should try to retain the current behavior.
I wonder, though, if the return value should be
(ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE)
Thanks,
Rafael
> -----Original Message-----
> From: Lin, Ming M
> Sent: Tuesday, December 14, 2010 11:47 PM
> To: lenb
> Cc: Moore, Robert; Rafael J. Wysocki; linux-acpi
> Subject: [PATCH] acpi: update return value in EC gpe handler
>
> EC gpe handler should return ACPI_REENABLE_GPE, so acpi_ev_gpe_dispatch
> can clear and reenable the GPE.
>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
>
> Len,
>
> I forgot to update EC gpe handler return value in the series of
> "[PATCH v2 0/8] Minimize ACPICA/linux GPE code divergence".
> This is the fix.
>
> drivers/acpi/ec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index e15439a..8a0e907 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -619,7 +619,7 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
> wake_up(&ec->wait);
> ec_check_sci(ec, acpi_ec_read_status(ec));
> }
> - return ACPI_INTERRUPT_HANDLED;
> + return ACPI_REENABLE_GPE;
> }
>
> /* --------------------------------------------------------------------------
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-12-17 22:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-15 7:47 [PATCH] acpi: update return value in EC gpe handler Lin Ming
2010-12-15 20:04 ` Moore, Robert
2010-12-17 22:17 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox