Message-ID: <4911F71203A09E4D9981D27F9D830858B4893B89@orsmsx503.amr.corp.intel.com>
Date:	Wed, 6 Oct 2010 09:14:07 -0700
From:	"Moore, Robert" <robert.moore@...el.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>, Matthew Garrett <mjg@...hat.com>
CC:	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: RE: [PATCH 1/5] ACPI: Allow handlers to be installed at the same
 time as methods



>In fact, what we need to handle is the case in which a GPE is pointed to by
>a _PRW method somewhere and we presume that it's necessary to execute
>Notify() for it regardless of whether or not it has a method, right?



Although there exists a single Windows document mentions this behavior as a windows "feature", I'm not 100% convinced that this is actually true. AFAIK, we've never seen a machine that depends on an "implicit notify" on a device when a wake GPE happens.

That being said, we should probably think about how to implement this if and when it becomes a requirement.

It appears to me that the biggest issue right now is the fact that a Notify() must be performed on a Device object, and the problem is how to associate the GPE with the device object.

In the past, when ACPICA was executing the _PRW methods during initialization, it would have been simple to detect the condition where a _PRW method referenced a GPE that had no GPE method -- and then make an association of the _PRW device with the GPE for use later to generate an implicit notify.

Now that ACPICA no longer executes the _PRW methods, there are two pieces of information that it no longer has:

1) It does not know which GPEs can be used to wake the system. The new GPE model allows the host to tell ACPICA about these GPEs as they are discovered during the _PRW method execution phase.

2) It has no knowledge of which devices are associated with the wake GPEs.

Perhaps we should add some ability for the host to inform ACPICA of the device object associated with the _PRW (in addition to the actual GPE).

Bob



>-----Original Message-----
>From: Rafael J. Wysocki [mailto:rjw@...k.pl]
>Sent: Tuesday, October 05, 2010 4:19 PM
>To: Matthew Garrett
>Cc: linux-acpi@...r.kernel.org; linux-kernel@...r.kernel.org; linux-
>pci@...r.kernel.org; Moore, Robert
>Subject: Re: [PATCH 1/5] ACPI: Allow handlers to be installed at the same
>time as methods
>
>On Monday, October 04, 2010, Matthew Garrett wrote:
>> There are circumstances under which it may be desirable for GPE handlers
>> to be installable without displacing the existing GPE method. Add support
>> for this via a boolean argument to acpi_install_gpe_handler, and fix up
>the
>> existing users to ensure that their behaviour doesn't change.
>
>Hmm.  I'm not sure this is the best way to do that.
>
>In fact, what we need to handle is the case in which a GPE is pointed to by
>a _PRW method somewhere and we presume that it's necessary to execute
>Notify() for it regardless of whether or not it has a method, right?
>
>So, this GPE will have ACPI_GPE_CAN_WAKE, so can we just put something like
>
>if (gpe_event_info->flags & ACPI_GPE_CAN_WAKE)
>         execute Notify()
>
>somewhere around the switch statement in acpi_ev_gpe_dispatch()?
>
>Or perhaps replace acpi_ev_asynch_enable_gpe() with something that will
>execute Notify() and then do what the original acpi_ev_asynch_enable_gpe()
>does?
>
>That should be easier to implement after the changes we've been discussing
>with
>Bob recently (basically, handle both GPE handlers and _Lxx/_Exx
>analogously).
>
>Rafael
--
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