Fix wake GPE enabling

Fix wake GPE enabling

[Dominik Brodowski]

While trying to get ACPI sleep states to run on my three test systems, I
found these bugs in ACPI's handling of the GPE blocks:

1.) gpe_block->wake_enable is zero, as even for ACPI_GPE_TYPE_WAKE
    discovered during boot no call to acpi_hw_enable_gpe_for_wakeup() is
    done.

2.) The if-wrapping by acpi_gbl_leave_wake_gpes_disabled around the
    acpi_ev_get_gpe_type walk caused that there is done no distinction
    between TYPE_WAKE and TYPE_RUNTIME --> gpe_block->wake_enable would
    _stay_ zero.

So, the attached patch does the following things:

- enable TYPE_WAKE GPEs for wakeup
- unconditionally differenciate between TYPE_WAKE and TYPE_RUNTIME GPEs
- if acpi_gbl_leave_wake_gpes_disabled is set, skip the runtime enabling
  of TYPE_WAKE GPEs
- else enable all (TYPE_WAKE and TYPE_RUNTIME) GPEs.

With this patch, my Centrino notebook resumes from S3, network et al. works
fine, but the screen stays dark... without this patch, I can press the power
button for minutes, and nothing happens.

BTW, Intel may incorporate this diff into their OS-independent ACPI
distribution... all stuff below drivers/acpi/* is in there, isn't it?

diff -ruN linux-original/drivers/acpi/events/evgpeblk.c linux/drivers/acpi/events/evgpeblk.c
--- linux-original/drivers/acpi/events/evgpeblk.c	2004-04-06 21:04:18.000000000 +0200
+++ linux/drivers/acpi/events/evgpeblk.c	2004-04-07 22:09:31.129961936 +0200
@@ -374,6 +374,7 @@
 
 		gpe_event_info = &gpe_block->event_info[gpe_number - gpe_block->block_base_number];
 		gpe_event_info->flags |= ACPI_GPE_TYPE_WAKE;
+		acpi_hw_enable_gpe_for_wakeup(gpe_event_info);
 	}
 
 cleanup:
@@ -813,6 +814,7 @@
 	acpi_native_uint                i;
 	acpi_native_uint                j;
 	u32                             wake_gpe_count;
+	u32                             runtime_gpe_count;
 	u32                             gpe_enabled_count;
 	acpi_status                     status;
 	struct acpi_gpe_walk_info       gpe_info;
@@ -874,28 +876,21 @@
 
 	/*
 	 * Runtime option: Should Wake GPEs be enabled at runtime?  The default is
-	 * No,they should only be enabled just as the machine goes to sleep.
+	 * Yes, by Linus' opinion.
+	 *
+	 * Differentiate RUNTIME vs WAKE GPEs, via the _PRW control methods. (Each
+	 * GPE that has one or more _PRWs that reference it is by definition a
+	 * WAKE GPE and will not be enabled while the machine is running.)
 	 */
-	if (acpi_gbl_leave_wake_gpes_disabled) {
-		/*
-		 * Differentiate RUNTIME vs WAKE GPEs, via the _PRW control methods. (Each
-		 * GPE that has one or more _PRWs that reference it is by definition a
-		 * WAKE GPE and will not be enabled while the machine is running.)
-		 */
-		gpe_info.gpe_block = gpe_block;
-		gpe_info.gpe_device = gpe_device;
+	gpe_info.gpe_block = gpe_block;
+	gpe_info.gpe_device = gpe_device;
 
-		status = acpi_ns_walk_namespace (ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
-				  ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK, acpi_ev_get_gpe_type,
-				  &gpe_info, NULL);
-	}
+	status = acpi_ns_walk_namespace (ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+					 ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK, acpi_ev_get_gpe_type,
+					 &gpe_info, NULL);
 
-	/*
-	 * Enable all GPEs in this block that are 1) "runtime" GPEs, and 2) have
-	 * a corresponding _Lxx or _Exx method.  All other GPEs must be enabled via
-	 * the acpi_enable_gpe() external interface.
-	 */
 	wake_gpe_count = 0;
+	runtime_gpe_count = 0;
 	gpe_enabled_count = 0;
 
 	for (i = 0; i < gpe_block->register_count; i++) {
@@ -903,9 +898,14 @@
 			/* Get the info block for this particular GPE */
 
 			gpe_event_info = &gpe_block->event_info[(i * ACPI_GPE_REGISTER_WIDTH) + j];
-			if ((gpe_event_info->method_node) &&
-			   ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_RUNTIME)) {
-				/* Enable this GPE, it is 1) RUNTIME and 2) has an _Lxx or _Exx method */
+			if (gpe_event_info->method_node) {
+				if ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_WAKE) {
+					wake_gpe_count++;
+					if (acpi_gbl_leave_wake_gpes_disabled)
+						continue;
+				} else if ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_RUNTIME) {
+					runtime_gpe_count++;
+				}
 
 				status = acpi_hw_enable_gpe (gpe_event_info);
 				if (ACPI_FAILURE (status)) {
@@ -913,16 +913,12 @@
 				}
 				gpe_enabled_count++;
 			}
-
-			if ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_WAKE) {
-				wake_gpe_count++;
-			}
 		}
 	}
 
 	ACPI_DEBUG_PRINT ((ACPI_DB_INIT,
-			"Found %u Wake, Enabled %u Runtime GPEs in this block\n",
-			wake_gpe_count, gpe_enabled_count));
+			"Found %u Wake, %u Runtime GPEs in this block, and enabled %u of them\n",
+			wake_gpe_count, runtime_gpe_count, gpe_enabled_count));
 
 	/* Return the new block */
 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

RE: Fix wake GPE enabling

[Moore, Robert]

No, this does not fit the model correctly.

It is the responsibility of the upper software to selectively enable the
devices which are to be used for wakeup.  This is one of the functions
of the AcpiGpeEnable interface.  The ACPI CA core cannot just blindly
enable all "wake" GPEs.

The ACPI CA core simply identifies the "wake" GPEs in order to leave
them disabled during runtime.

Therefore, in (1) and (2) below, this is the correct behavior.  No
"wake" GPEs are enabled.

Bob


-----Original Message-----
From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Dominik
Brodowski
Sent: Wednesday, April 07, 2004 1:54 PM
To: Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [ACPI] Fix wake GPE enabling

While trying to get ACPI sleep states to run on my three test systems, I
found these bugs in ACPI's handling of the GPE blocks:

1.) gpe_block->wake_enable is zero, as even for ACPI_GPE_TYPE_WAKE
    discovered during boot no call to acpi_hw_enable_gpe_for_wakeup() is
    done.

2.) The if-wrapping by acpi_gbl_leave_wake_gpes_disabled around the
    acpi_ev_get_gpe_type walk caused that there is done no distinction
    between TYPE_WAKE and TYPE_RUNTIME --> gpe_block->wake_enable would
    _stay_ zero.

So, the attached patch does the following things:

- enable TYPE_WAKE GPEs for wakeup
- unconditionally differenciate between TYPE_WAKE and TYPE_RUNTIME GPEs
- if acpi_gbl_leave_wake_gpes_disabled is set, skip the runtime enabling
  of TYPE_WAKE GPEs
- else enable all (TYPE_WAKE and TYPE_RUNTIME) GPEs.

With this patch, my Centrino notebook resumes from S3, network et al.
works
fine, but the screen stays dark... without this patch, I can press the
power
button for minutes, and nothing happens.

BTW, Intel may incorporate this diff into their OS-independent ACPI
distribution... all stuff below drivers/acpi/* is in there, isn't it?

diff -ruN linux-original/drivers/acpi/events/evgpeblk.c
linux/drivers/acpi/events/evgpeblk.c
--- linux-original/drivers/acpi/events/evgpeblk.c	2004-04-06
21:04:18.000000000 +0200
+++ linux/drivers/acpi/events/evgpeblk.c	2004-04-07
22:09:31.129961936 +0200
@@ -374,6 +374,7 @@
 
 		gpe_event_info = &gpe_block->event_info[gpe_number -
gpe_block->block_base_number];
 		gpe_event_info->flags |= ACPI_GPE_TYPE_WAKE;
+		acpi_hw_enable_gpe_for_wakeup(gpe_event_info);
 	}
 
 cleanup:
@@ -813,6 +814,7 @@
 	acpi_native_uint                i;
 	acpi_native_uint                j;
 	u32                             wake_gpe_count;
+	u32                             runtime_gpe_count;
 	u32                             gpe_enabled_count;
 	acpi_status                     status;
 	struct acpi_gpe_walk_info       gpe_info;
@@ -874,28 +876,21 @@
 
 	/*
 	 * Runtime option: Should Wake GPEs be enabled at runtime?  The
default is
-	 * No,they should only be enabled just as the machine goes to
sleep.
+	 * Yes, by Linus' opinion.
+	 *
+	 * Differentiate RUNTIME vs WAKE GPEs, via the _PRW control
methods. (Each
+	 * GPE that has one or more _PRWs that reference it is by
definition a
+	 * WAKE GPE and will not be enabled while the machine is
running.)
 	 */
-	if (acpi_gbl_leave_wake_gpes_disabled) {
-		/*
-		 * Differentiate RUNTIME vs WAKE GPEs, via the _PRW
control methods. (Each
-		 * GPE that has one or more _PRWs that reference it is
by definition a
-		 * WAKE GPE and will not be enabled while the machine is
running.)
-		 */
-		gpe_info.gpe_block = gpe_block;
-		gpe_info.gpe_device = gpe_device;
+	gpe_info.gpe_block = gpe_block;
+	gpe_info.gpe_device = gpe_device;
 
-		status = acpi_ns_walk_namespace (ACPI_TYPE_DEVICE,
ACPI_ROOT_OBJECT,
-				  ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK,
acpi_ev_get_gpe_type,
-				  &gpe_info, NULL);
-	}
+	status = acpi_ns_walk_namespace (ACPI_TYPE_DEVICE,
ACPI_ROOT_OBJECT,
+					 ACPI_UINT32_MAX,
ACPI_NS_WALK_UNLOCK, acpi_ev_get_gpe_type,
+					 &gpe_info, NULL);
 
-	/*
-	 * Enable all GPEs in this block that are 1) "runtime" GPEs, and
2) have
-	 * a corresponding _Lxx or _Exx method.  All other GPEs must be
enabled via
-	 * the acpi_enable_gpe() external interface.
-	 */
 	wake_gpe_count = 0;
+	runtime_gpe_count = 0;
 	gpe_enabled_count = 0;
 
 	for (i = 0; i < gpe_block->register_count; i++) {
@@ -903,9 +898,14 @@
 			/* Get the info block for this particular GPE */
 
 			gpe_event_info = &gpe_block->event_info[(i *
ACPI_GPE_REGISTER_WIDTH) + j];
-			if ((gpe_event_info->method_node) &&
-			   ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK)
== ACPI_GPE_TYPE_RUNTIME)) {
-				/* Enable this GPE, it is 1) RUNTIME and
2) has an _Lxx or _Exx method */
+			if (gpe_event_info->method_node) {
+				if ((gpe_event_info->flags &
ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_WAKE) {
+					wake_gpe_count++;
+					if
(acpi_gbl_leave_wake_gpes_disabled)
+						continue;
+				} else if ((gpe_event_info->flags &
ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_RUNTIME) {
+					runtime_gpe_count++;
+				}
 
 				status = acpi_hw_enable_gpe
(gpe_event_info);
 				if (ACPI_FAILURE (status)) {
@@ -913,16 +913,12 @@
 				}
 				gpe_enabled_count++;
 			}
-
-			if ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK)
== ACPI_GPE_TYPE_WAKE) {
-				wake_gpe_count++;
-			}
 		}
 	}
 
 	ACPI_DEBUG_PRINT ((ACPI_DB_INIT,
-			"Found %u Wake, Enabled %u Runtime GPEs in this
block\n",
-			wake_gpe_count, gpe_enabled_count));
+			"Found %u Wake, %u Runtime GPEs in this block,
and enabled %u of them\n",
+			wake_gpe_count, runtime_gpe_count,
gpe_enabled_count));
 
 	/* Return the new block */
 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

RE: Fix wake GPE enabling

[Manpreet Singh]

Robert,

How about a /proc or /sys interface that calls AcpiEnableGpe and/or alters
the WakeEnable vector? Would that be consistent?

In what other ways do you suggest exporting this to the user space?

Thanks,
Manpreet.


-----Original Message-----
From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org]On Behalf Of Moore,
Robert
Sent: Wednesday, April 07, 2004 2:35 PM
To: Dominik Brodowski; Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Cc: Grover, Andrew
Subject: RE: [ACPI] Fix wake GPE enabling



No, this does not fit the model correctly.

It is the responsibility of the upper software to selectively enable the
devices which are to be used for wakeup.  This is one of the functions
of the AcpiGpeEnable interface.  The ACPI CA core cannot just blindly
enable all "wake" GPEs.

The ACPI CA core simply identifies the "wake" GPEs in order to leave
them disabled during runtime.

Therefore, in (1) and (2) below, this is the correct behavior.  No
"wake" GPEs are enabled.

Bob


-----Original Message-----
From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Dominik
Brodowski
Sent: Wednesday, April 07, 2004 1:54 PM
To: Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [ACPI] Fix wake GPE enabling

While trying to get ACPI sleep states to run on my three test systems, I
found these bugs in ACPI's handling of the GPE blocks:

1.) gpe_block->wake_enable is zero, as even for ACPI_GPE_TYPE_WAKE
    discovered during boot no call to acpi_hw_enable_gpe_for_wakeup() is
    done.

2.) The if-wrapping by acpi_gbl_leave_wake_gpes_disabled around the
    acpi_ev_get_gpe_type walk caused that there is done no distinction
    between TYPE_WAKE and TYPE_RUNTIME --> gpe_block->wake_enable would
    _stay_ zero.

So, the attached patch does the following things:

- enable TYPE_WAKE GPEs for wakeup
- unconditionally differenciate between TYPE_WAKE and TYPE_RUNTIME GPEs
- if acpi_gbl_leave_wake_gpes_disabled is set, skip the runtime enabling
  of TYPE_WAKE GPEs
- else enable all (TYPE_WAKE and TYPE_RUNTIME) GPEs.

With this patch, my Centrino notebook resumes from S3, network et al.
works
fine, but the screen stays dark... without this patch, I can press the
power
button for minutes, and nothing happens.

BTW, Intel may incorporate this diff into their OS-independent ACPI
distribution... all stuff below drivers/acpi/* is in there, isn't it?

diff -ruN linux-original/drivers/acpi/events/evgpeblk.c
linux/drivers/acpi/events/evgpeblk.c
--- linux-original/drivers/acpi/events/evgpeblk.c	2004-04-06
21:04:18.000000000 +0200
+++ linux/drivers/acpi/events/evgpeblk.c	2004-04-07
22:09:31.129961936 +0200
@@ -374,6 +374,7 @@
 
 		gpe_event_info = &gpe_block->event_info[gpe_number -
gpe_block->block_base_number];
 		gpe_event_info->flags |= ACPI_GPE_TYPE_WAKE;
+		acpi_hw_enable_gpe_for_wakeup(gpe_event_info);
 	}
 
 cleanup:
@@ -813,6 +814,7 @@
 	acpi_native_uint                i;
 	acpi_native_uint                j;
 	u32                             wake_gpe_count;
+	u32                             runtime_gpe_count;
 	u32                             gpe_enabled_count;
 	acpi_status                     status;
 	struct acpi_gpe_walk_info       gpe_info;
@@ -874,28 +876,21 @@
 
 	/*
 	 * Runtime option: Should Wake GPEs be enabled at runtime?  The
default is
-	 * No,they should only be enabled just as the machine goes to
sleep.
+	 * Yes, by Linus' opinion.
+	 *
+	 * Differentiate RUNTIME vs WAKE GPEs, via the _PRW control
methods. (Each
+	 * GPE that has one or more _PRWs that reference it is by
definition a
+	 * WAKE GPE and will not be enabled while the machine is
running.)
 	 */
-	if (acpi_gbl_leave_wake_gpes_disabled) {
-		/*
-		 * Differentiate RUNTIME vs WAKE GPEs, via the _PRW
control methods. (Each
-		 * GPE that has one or more _PRWs that reference it is
by definition a
-		 * WAKE GPE and will not be enabled while the machine is
running.)
-		 */
-		gpe_info.gpe_block = gpe_block;
-		gpe_info.gpe_device = gpe_device;
+	gpe_info.gpe_block = gpe_block;
+	gpe_info.gpe_device = gpe_device;
 
-		status = acpi_ns_walk_namespace (ACPI_TYPE_DEVICE,
ACPI_ROOT_OBJECT,
-				  ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK,
acpi_ev_get_gpe_type,
-				  &gpe_info, NULL);
-	}
+	status = acpi_ns_walk_namespace (ACPI_TYPE_DEVICE,
ACPI_ROOT_OBJECT,
+					 ACPI_UINT32_MAX,
ACPI_NS_WALK_UNLOCK, acpi_ev_get_gpe_type,
+					 &gpe_info, NULL);
 
-	/*
-	 * Enable all GPEs in this block that are 1) "runtime" GPEs, and
2) have
-	 * a corresponding _Lxx or _Exx method.  All other GPEs must be
enabled via
-	 * the acpi_enable_gpe() external interface.
-	 */
 	wake_gpe_count = 0;
+	runtime_gpe_count = 0;
 	gpe_enabled_count = 0;
 
 	for (i = 0; i < gpe_block->register_count; i++) {
@@ -903,9 +898,14 @@
 			/* Get the info block for this particular GPE */
 
 			gpe_event_info = &gpe_block->event_info[(i *
ACPI_GPE_REGISTER_WIDTH) + j];
-			if ((gpe_event_info->method_node) &&
-			   ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK)
== ACPI_GPE_TYPE_RUNTIME)) {
-				/* Enable this GPE, it is 1) RUNTIME and
2) has an _Lxx or _Exx method */
+			if (gpe_event_info->method_node) {
+				if ((gpe_event_info->flags &
ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_WAKE) {
+					wake_gpe_count++;
+					if
(acpi_gbl_leave_wake_gpes_disabled)
+						continue;
+				} else if ((gpe_event_info->flags &
ACPI_GPE_TYPE_MASK) == ACPI_GPE_TYPE_RUNTIME) {
+					runtime_gpe_count++;
+				}
 
 				status = acpi_hw_enable_gpe
(gpe_event_info);
 				if (ACPI_FAILURE (status)) {
@@ -913,16 +913,12 @@
 				}
 				gpe_enabled_count++;
 			}
-
-			if ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK)
== ACPI_GPE_TYPE_WAKE) {
-				wake_gpe_count++;
-			}
 		}
 	}
 
 	ACPI_DEBUG_PRINT ((ACPI_DB_INIT,
-			"Found %u Wake, Enabled %u Runtime GPEs in this
block\n",
-			wake_gpe_count, gpe_enabled_count));
+			"Found %u Wake, %u Runtime GPEs in this block,
and enabled %u of them\n",
+			wake_gpe_count, runtime_gpe_count,
gpe_enabled_count));
 
 	/* Return the new block */
 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=ick
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

Re: Fix wake GPE enabling

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

On Wed, Apr 07, 2004 at 02:34:43PM -0700, Moore, Robert wrote:
> 
> No, this does not fit the model correctly.
> 
> It is the responsibility of the upper software to selectively enable the
> devices which are to be used for wakeup.  This is one of the functions
> of the AcpiGpeEnable interface.  The ACPI CA core cannot just blindly
> enable all "wake" GPEs.

However, the ACPI subsystem, and I do not care whether it is the CA core or
any other part, currently does not enable any(!) wake GPEs.

-> wake_enable is not touched directly,
-> events/evgpeblk.c does not care, and according to your opinion, should
   not care.
-> acpi_enable_gpe is _only_ called by drivers/acpi/ec.c, which means it is
   _not_ called for buttons, which are very clearly needed in most cases to
   wake up a system.

At least for buttons, the ACPI subsystem should enable their wake
functionality, e.g. the wake GPEs, unconditionally. Having to manually enter
"echo powerbutton > /proc/acpi/wakeup_devices", as the patch in bug #1415
suggests, seems to be overly complicated. However, having this file as
override might be a valid option, I agree.

> The ACPI CA core simply identifies the "wake" GPEs in order to leave
> them disabled during runtime.
> 
> Therefore, in (1) and (2) below, this is the correct behavior.  No
> "wake" GPEs are enabled.

IMHO, (2) is not correct behavior. It is a different thing to
- disable wake GPEs during runtime,
and
- mark wake GPEs as runtime GPEs, which is what the current code does.

Also, as it has been experienced by Linus, for example[*], some "wake" GPEs are also useful to
have during runtime, so the code in acpi_enable_gpe() which disables a GPE
marked as "wake" is flawed. IMO it should be able to set it to both RUNTIME and
WAKE, if it's runtime, enable it during runtime, if it's wake, enable it for
wakeup.

[*] And that's the reason the acpi_disable_wake_gpes_during_runtime flag is
_not_ set to true in Linux 2.6.5, in contrast to the original ACPI patch
sent out. And I'm glad it is this way: with this flag set, my notebook's
keyboard stops functioning...

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fix wake GPE enabling

[Takayoshi Kochi]

Hi,

From: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: RE: [ACPI] Fix wake GPE enabling
Date: Wed, 7 Apr 2004 14:34:43 -0700

> 
> No, this does not fit the model correctly.
> 
> It is the responsibility of the upper software to selectively enable the
> devices which are to be used for wakeup.  This is one of the functions
> of the AcpiGpeEnable interface.  The ACPI CA core cannot just blindly
> enable all "wake" GPEs.
> 
> The ACPI CA core simply identifies the "wake" GPEs in order to leave
> them disabled during runtime.

Hm, I might be misunderstanding, but my understanding is as follows
(this almost agrees with Dominik's second post):

1. Wake GPEs and runtime GPEs are _not_ exclusive but overwrapping
   by default.
   (Is it _explicitly_ stated in the spec that Wake GPE and runtime
    GPEs are exclusive?)

2. All GPEs should be enabled by default.
   Because in many AMLs Non-Wake GPEs are also used as runtime
   GPEs and we can't ignore them.  Are there *any magic* by which
   OSPM can know which Wake GPE is also runtime GPE?
   Should we list all the combination of every existing BIOS
   and wake-and-runtime GPE? :)
   Providing an interface of specifying which Wake GPE is actually
   runtime GPE sounds very silly idea (as you know, most people are _not_
   acpi savvy and even ACPI hackers has to disassemble and understand
   which GPE does what for it).

3. Upon entering sleep state, all GPEs should be disabled except
   Wake GPEs for appropriate levels of sleep.  Current implementation
   ignores the second parameter of _PRW and thus it is considered
   incomplete, anyway.

   There might be APIs to set or reset the Wake flag (as well as
   lowest power state) of a GPE, in case one wants to set
   the flag manually, although the flag should be set
   automatically by parsing _PRW and these APIs are not needed usually.

   The ACPI_EVENT_WAKE_ENABLE flag for the AcpiEnableGpe()
   is unnecessary.

So from my understanding, the current implementation of
_PRW and Wake GPEs needs revamp.

Anyway, let's clarify what's wake GPEs and how to handle wake GPEs
first.

Dominik, thanks for throwing this issue into discussion.

---
Takayoshi Kochi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

RE: Fix wake GPE enabling

[Moore, Robert]

Comments below.

> -----Original Message-----
> From: Takayoshi Kochi [mailto:kochi-S783fYmB3Ccdnm+yROfE0A@public.gmane.org]
> Sent: Thursday, April 08, 2004 6:50 AM
> To: Moore, Robert
> Cc: linux-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org; Brown, Len; acpi-
> devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Grover, Andrew
> Subject: Re: [ACPI] Fix wake GPE enabling
> 
> Hi,
> 
> From: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Subject: RE: [ACPI] Fix wake GPE enabling
> Date: Wed, 7 Apr 2004 14:34:43 -0700
> 
> >
> > No, this does not fit the model correctly.
> >
> > It is the responsibility of the upper software to selectively enable
the
> > devices which are to be used for wakeup.  This is one of the
functions
> > of the AcpiGpeEnable interface.  The ACPI CA core cannot just
blindly
> > enable all "wake" GPEs.
> >
> > The ACPI CA core simply identifies the "wake" GPEs in order to leave
> > them disabled during runtime.
> 
> Hm, I might be misunderstanding, but my understanding is as follows
> (this almost agrees with Dominik's second post):
> 
> 1. Wake GPEs and runtime GPEs are _not_ exclusive but overwrapping
>    by default.
>    (Is it _explicitly_ stated in the spec that Wake GPE and runtime
>     GPEs are exclusive?)
> 
> 2. All GPEs should be enabled by default.
>    Because in many AMLs Non-Wake GPEs are also used as runtime
>    GPEs and we can't ignore them.  Are there *any magic* by which
>    OSPM can know which Wake GPE is also runtime GPE?

Not that I know of.  Wake and runtime GPEs should not be shared on the
same GPE, see below.

>    Should we list all the combination of every existing BIOS
>    and wake-and-runtime GPE? :)
>    Providing an interface of specifying which Wake GPE is actually
>    runtime GPE sounds very silly idea (as you know, most people are
_not_
>    acpi savvy and even ACPI hackers has to disassemble and understand
>    which GPE does what for it).


I'm not sure if this is explicitly stated in the spec.  However, here
are quotes from Microsoft (WinHec 2000)

General Purpose Event (GPE) Routing For The Windows Operating System 

Jake Oshins
Windows NT Base Development Lead 
Windows Division
Microsoft Corporation

GPE Architecture	
Golden rule
    Wake events and runtime events must not be shared on the same GPE


Processing Power Management Events 
In Windows 2000 

Stephane Plante
Windows NT Base Developer 
Windows Division
Microsoft Corporation

Windows 2000 will only enable GPE when OS has a device that is enabled
for wake-up

If the GPE is shared with RTC, Power, Sleep, or Lid switch the GPE will
always be enabled

Otherwise, GPE will only be enabled if there are devices that are
enabled 
for wake-up


> 
> 3. Upon entering sleep state, all GPEs should be disabled except
>    Wake GPEs for appropriate levels of sleep.  Current implementation
>    ignores the second parameter of _PRW and thus it is considered
>    incomplete, anyway.
> 

I believe that the second parameter of _PRW should be used by the upper
OSPM software, not the ACPI CA core subsystem.  The core only uses _PRW
to "identify" wake GPEs.

>    There might be APIs to set or reset the Wake flag (as well as
>    lowest power state) of a GPE, in case one wants to set
>    the flag manually, although the flag should be set
>    automatically by parsing _PRW and these APIs are not needed
usually.
> 
>    The ACPI_EVENT_WAKE_ENABLE flag for the AcpiEnableGpe()
>    is unnecessary.
> 

The purpose of ACPI_EVENT_WAKE_ENABLE is to allow the upper OSPM
software to enable individual wake GPEs for individual devices -- as per
this quote:

" Otherwise, GPE will only be enabled if there are devices that are
enabled 
for wake-up"

> So from my understanding, the current implementation of
> _PRW and Wake GPEs needs revamp.
> 

Linux needs a user interface and some additional OSPM software to
identify and program the wake devices, as well as handle the other
information in the _PRW methods.

Again, the core subsystem will only identify wake vs. runtime GPEs.

> Anyway, let's clarify what's wake GPEs and how to handle wake GPEs
> first.
> 
> Dominik, thanks for throwing this issue into discussion.
> 
> ---
> Takayoshi Kochi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

RE: Fix wake GPE enabling

[Moore, Robert]

Found something in the ACPI Specification:

Section 5.6.2.2.1, "Wake Events" (Under "General-Purpose Event Handling)

"Events that wake may not be intermixed with non-wake events on the same
GPE input. Also, all wake events not exclusively tied to a GPE input
(for example, one input is shared for multiple wake events) need to have
individual enable and status bits in order to properly handle the
semantics used by the system."

Bob


> -----Original Message-----
> From: Moore, Robert
> Sent: Thursday, April 08, 2004 9:01 AM
> To: 'Takayoshi Kochi'
> Cc: linux-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org; Brown, Len; acpi-
> devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Grover, Andrew
> Subject: RE: [ACPI] Fix wake GPE enabling
> 
> 
> Comments below.
> 
> > -----Original Message-----
> > From: Takayoshi Kochi [mailto:kochi-S783fYmB3Ccdnm+yROfE0A@public.gmane.org]
> > Sent: Thursday, April 08, 2004 6:50 AM
> > To: Moore, Robert
> > Cc: linux-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org; Brown, Len; acpi-
> > devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Grover, Andrew
> > Subject: Re: [ACPI] Fix wake GPE enabling
> >
> > Hi,
> >
> > From: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Subject: RE: [ACPI] Fix wake GPE enabling
> > Date: Wed, 7 Apr 2004 14:34:43 -0700
> >
> > >
> > > No, this does not fit the model correctly.
> > >
> > > It is the responsibility of the upper software to selectively
enable
> the
> > > devices which are to be used for wakeup.  This is one of the
functions
> > > of the AcpiGpeEnable interface.  The ACPI CA core cannot just
blindly
> > > enable all "wake" GPEs.
> > >
> > > The ACPI CA core simply identifies the "wake" GPEs in order to
leave
> > > them disabled during runtime.
> >
> > Hm, I might be misunderstanding, but my understanding is as follows
> > (this almost agrees with Dominik's second post):
> >
> > 1. Wake GPEs and runtime GPEs are _not_ exclusive but overwrapping
> >    by default.
> >    (Is it _explicitly_ stated in the spec that Wake GPE and runtime
> >     GPEs are exclusive?)
> >
> > 2. All GPEs should be enabled by default.
> >    Because in many AMLs Non-Wake GPEs are also used as runtime
> >    GPEs and we can't ignore them.  Are there *any magic* by which
> >    OSPM can know which Wake GPE is also runtime GPE?
> 
> Not that I know of.  Wake and runtime GPEs should not be shared on the
> same GPE, see below.
> 
> >    Should we list all the combination of every existing BIOS
> >    and wake-and-runtime GPE? :)
> >    Providing an interface of specifying which Wake GPE is actually
> >    runtime GPE sounds very silly idea (as you know, most people are
> _not_
> >    acpi savvy and even ACPI hackers has to disassemble and
understand
> >    which GPE does what for it).
> 
> 
> I'm not sure if this is explicitly stated in the spec.  However, here
are
> quotes from Microsoft (WinHec 2000)
> 
> General Purpose Event (GPE) Routing For The Windows Operating System
> 
> Jake Oshins
> Windows NT Base Development Lead
> Windows Division
> Microsoft Corporation
> 
> GPE Architecture
> Golden rule
>     Wake events and runtime events must not be shared on the same GPE
> 
> 
> Processing Power Management Events
> In Windows 2000
> 
> Stephane Plante
> Windows NT Base Developer
> Windows Division
> Microsoft Corporation
> 
> Windows 2000 will only enable GPE when OS has a device that is enabled
for
> wake-up
> 
> If the GPE is shared with RTC, Power, Sleep, or Lid switch the GPE
will
> always be enabled
> 
> Otherwise, GPE will only be enabled if there are devices that are
enabled
> for wake-up
> 
> 
> >
> > 3. Upon entering sleep state, all GPEs should be disabled except
> >    Wake GPEs for appropriate levels of sleep.  Current
implementation
> >    ignores the second parameter of _PRW and thus it is considered
> >    incomplete, anyway.
> >
> 
> I believe that the second parameter of _PRW should be used by the
upper
> OSPM software, not the ACPI CA core subsystem.  The core only uses
_PRW to
> "identify" wake GPEs.
> 
> >    There might be APIs to set or reset the Wake flag (as well as
> >    lowest power state) of a GPE, in case one wants to set
> >    the flag manually, although the flag should be set
> >    automatically by parsing _PRW and these APIs are not needed
usually.
> >
> >    The ACPI_EVENT_WAKE_ENABLE flag for the AcpiEnableGpe()
> >    is unnecessary.
> >
> 
> The purpose of ACPI_EVENT_WAKE_ENABLE is to allow the upper OSPM
software
> to enable individual wake GPEs for individual devices -- as per this
> quote:
> 
> " Otherwise, GPE will only be enabled if there are devices that are
> enabled
> for wake-up"
> 
> > So from my understanding, the current implementation of
> > _PRW and Wake GPEs needs revamp.
> >
> 
> Linux needs a user interface and some additional OSPM software to
identify
> and program the wake devices, as well as handle the other information
in
> the _PRW methods.
> 
> Again, the core subsystem will only identify wake vs. runtime GPEs.
> 
> > Anyway, let's clarify what's wake GPEs and how to handle wake GPEs
> > first.
> >
> > Dominik, thanks for throwing this issue into discussion.
> >
> > ---
> > Takayoshi Kochi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

RE: Fix wake GPE enabling

[Moore, Robert]

Comments below.

> -----Original Message-----
> From: Dominik Brodowski [mailto:linux-X3ehHDuj6sIIGcDfoQAp7BvVK+yQ3ZXh@public.gmane.org]
> Sent: Wednesday, April 07, 2004 11:45 PM
> To: Moore, Robert
> Cc: Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Grover, Andrew
> Subject: Re: [ACPI] Fix wake GPE enabling
> 
> On Wed, Apr 07, 2004 at 02:34:43PM -0700, Moore, Robert wrote:
> >
> > No, this does not fit the model correctly.
> >
> > It is the responsibility of the upper software to selectively enable
the
> > devices which are to be used for wakeup.  This is one of the
functions
> > of the AcpiGpeEnable interface.  The ACPI CA core cannot just
blindly
> > enable all "wake" GPEs.
> 
> However, the ACPI subsystem, and I do not care whether it is the CA
core
> or
> any other part, currently does not enable any(!) wake GPEs.
> 

Linux needs a user interface and some additional OSPM software to
identify and program the wake devices, as well as handle the other
information in the _PRW methods.

The ACPI CA core subsystem will only identify wake vs. runtime GPEs.

> -> wake_enable is not touched directly,
> -> events/evgpeblk.c does not care, and according to your opinion,
should
>    not care.
> -> acpi_enable_gpe is _only_ called by drivers/acpi/ec.c, which means
it
> is
>    _not_ called for buttons, which are very clearly needed in most
cases
> to
>    wake up a system.
> 
> At least for buttons, the ACPI subsystem should enable their wake
> functionality, e.g. the wake GPEs, unconditionally. Having to manually
> enter
> "echo powerbutton > /proc/acpi/wakeup_devices", as the patch in bug
#1415
> suggests, seems to be overly complicated. However, having this file as
> override might be a valid option, I agree.
> 

The ACPI CA core subsystem does NOT scan for particular devices (via the
_HID, _UID, etc.)  The upper OSPM software already does this and is thus
responsible for enabling individual devices and GPEs for wake-up,
including the power button, lid button, etc.  This code apparently still
needs to be written.


> > The ACPI CA core simply identifies the "wake" GPEs in order to leave
> > them disabled during runtime.
> >
> > Therefore, in (1) and (2) below, this is the correct behavior.  No
> > "wake" GPEs are enabled.
> 
> IMHO, (2) is not correct behavior. It is a different thing to
> - disable wake GPEs during runtime,
> and
> - mark wake GPEs as runtime GPEs, which is what the current code does.
> 

The purpose of the global flag is to either enable the differentiation
between wake/runtime GPEs or just ignore the difference and enable ALL
GPEs with a corresponding _Lxx or _Exx method at runtime (The latter is
the original behavior of the CA subsystem).

Probably the global could be named better, however.


> Also, as it has been experienced by Linus, for example[*], some "wake"
> GPEs are also useful to
> have during runtime, so the code in acpi_enable_gpe() which disables a
GPE
> marked as "wake" is flawed. IMO it should be able to set it to both
> RUNTIME and
> WAKE, if it's runtime, enable it during runtime, if it's wake, enable
it
> for
> wakeup.

>From the ACPI Specification 2.0C:

Section 5.6.2.2.1, "Wake Events" (Under "General-Purpose Event Handling)

"Events that wake may not be intermixed with non-wake events on the same
GPE input."

> 
> [*] And that's the reason the acpi_disable_wake_gpes_during_runtime
flag
> is
> _not_ set to true in Linux 2.6.5, in contrast to the original ACPI
patch
> sent out. And I'm glad it is this way: with this flag set, my
notebook's
> keyboard stops functioning...
> 
> 	Dominik


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

RE: Fix wake GPE enabling

[Nate Lawson]

On Thu, 8 Apr 2004, Moore, Robert wrote:
> Linux needs a user interface and some additional OSPM software to
> identify and program the wake devices, as well as handle the other
> information in the _PRW methods.
>
> The ACPI CA core subsystem will only identify wake vs. runtime GPEs.
>
> > -> wake_enable is not touched directly,
> > -> events/evgpeblk.c does not care, and according to your opinion,
> should
> >    not care.
> > -> acpi_enable_gpe is _only_ called by drivers/acpi/ec.c, which means
> it
> > is
> >    _not_ called for buttons, which are very clearly needed in most
> cases
> > to
> >    wake up a system.
> >
> > At least for buttons, the ACPI subsystem should enable their wake
> > functionality, e.g. the wake GPEs, unconditionally. Having to manually
> > enter
> > "echo powerbutton > /proc/acpi/wakeup_devices", as the patch in bug
> #1415
> > suggests, seems to be overly complicated. However, having this file as
> > override might be a valid option, I agree.
> >
>
> The ACPI CA core subsystem does NOT scan for particular devices (via the
> _HID, _UID, etc.)  The upper OSPM software already does this and is thus
> responsible for enabling individual devices and GPEs for wake-up,
> including the power button, lid button, etc.  This code apparently still
> needs to be written.

You mean like this code snippet?

-Nate

acpi_button_attach(device_t dev)
{
    if (sc->fixed) {
        AcpiClearEvent(event);
        status = AcpiInstallFixedEventHandler(event,
                        acpi_button_fixed_handler, sc);
    } else {
        status = AcpiInstallNotifyHandler(sc->button_handle,
                        ACPI_DEVICE_NOTIFY, acpi_button_notify_handler, sc);
    }

    acpi_device_enable_wake_capability(sc->button_handle, 1);
}

acpi_button_suspend(device_t dev)
{
    struct acpi_button_softc    *sc;

    sc = device_get_softc(dev);
    acpi_device_enable_wake_event(sc->button_handle);
    return (0);
}

acpi_device_enable_wake_capability(ACPI_HANDLE h, int enable)
{
    /*
     * All Power Resources referenced by elements 2 through N
     * of the _PRW object are put into the ON state.
     */

    (void)acpi_SetInteger(h, "_PSW", enable);
}

acpi_device_enable_wake_event(ACPI_HANDLE h)
{
    status = AcpiEvaluateObject(h, "_PRW", NULL, &prw_buffer);
    if (ACPI_FAILURE(status))
        return;

    switch (res->Package.Elements[0].Type) {
    case ACPI_TYPE_INTEGER:
        /*
         * If the data type of this package element is numeric, then this
         * _PRW package element is the bit index in the GPEx_EN, in the
         * GPE blocks described in the FADT, of the enable bit that is
         * enabled for the wake event.
         */
        status = AcpiEnableGpe(NULL, res->Package.Elements[0].Integer.Value,
                               ACPI_EVENT_WAKE_ENABLE);
}


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

RE: Fix wake GPE enabling

[Moore, Robert]

Nate,

Yes, the code below looks good.  This is the model that we have in mind
for the ACPI CA code, OSPM, and individual drivers.

Bob


> -----Original Message-----
> From: Nate Lawson [mailto:nate-Y6VGUYTwhu0@public.gmane.org]
> Sent: Thursday, April 08, 2004 10:48 AM
> To: Moore, Robert
> Cc: Dominik Brodowski; Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org;
> Grover, Andrew
> Subject: RE: [ACPI] Fix wake GPE enabling
> 
> On Thu, 8 Apr 2004, Moore, Robert wrote:
> > Linux needs a user interface and some additional OSPM software to
> > identify and program the wake devices, as well as handle the other
> > information in the _PRW methods.
> >
> > The ACPI CA core subsystem will only identify wake vs. runtime GPEs.
> >
> > > -> wake_enable is not touched directly,
> > > -> events/evgpeblk.c does not care, and according to your opinion,
> > should
> > >    not care.
> > > -> acpi_enable_gpe is _only_ called by drivers/acpi/ec.c, which
means
> > it
> > > is
> > >    _not_ called for buttons, which are very clearly needed in most
> > cases
> > > to
> > >    wake up a system.
> > >
> > > At least for buttons, the ACPI subsystem should enable their wake
> > > functionality, e.g. the wake GPEs, unconditionally. Having to
manually
> > > enter
> > > "echo powerbutton > /proc/acpi/wakeup_devices", as the patch in
bug
> > #1415
> > > suggests, seems to be overly complicated. However, having this
file as
> > > override might be a valid option, I agree.
> > >
> >
> > The ACPI CA core subsystem does NOT scan for particular devices (via
the
> > _HID, _UID, etc.)  The upper OSPM software already does this and is
thus
> > responsible for enabling individual devices and GPEs for wake-up,
> > including the power button, lid button, etc.  This code apparently
still
> > needs to be written.
> 
> You mean like this code snippet?
> 
> -Nate
> 
> acpi_button_attach(device_t dev)
> {
>     if (sc->fixed) {
>         AcpiClearEvent(event);
>         status = AcpiInstallFixedEventHandler(event,
>                         acpi_button_fixed_handler, sc);
>     } else {
>         status = AcpiInstallNotifyHandler(sc->button_handle,
>                         ACPI_DEVICE_NOTIFY,
acpi_button_notify_handler,
> sc);
>     }
> 
>     acpi_device_enable_wake_capability(sc->button_handle, 1);
> }
> 
> acpi_button_suspend(device_t dev)
> {
>     struct acpi_button_softc    *sc;
> 
>     sc = device_get_softc(dev);
>     acpi_device_enable_wake_event(sc->button_handle);
>     return (0);
> }
> 
> acpi_device_enable_wake_capability(ACPI_HANDLE h, int enable)
> {
>     /*
>      * All Power Resources referenced by elements 2 through N
>      * of the _PRW object are put into the ON state.
>      */
> 
>     (void)acpi_SetInteger(h, "_PSW", enable);
> }
> 
> acpi_device_enable_wake_event(ACPI_HANDLE h)
> {
>     status = AcpiEvaluateObject(h, "_PRW", NULL, &prw_buffer);
>     if (ACPI_FAILURE(status))
>         return;
> 
>     switch (res->Package.Elements[0].Type) {
>     case ACPI_TYPE_INTEGER:
>         /*
>          * If the data type of this package element is numeric, then
this
>          * _PRW package element is the bit index in the GPEx_EN, in
the
>          * GPE blocks described in the FADT, of the enable bit that is
>          * enabled for the wake event.
>          */
>         status = AcpiEnableGpe(NULL, res-
> >Package.Elements[0].Integer.Value,
>                                ACPI_EVENT_WAKE_ENABLE);
> }


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

Re: Fix wake GPE enabling

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Thu, Apr 08, 2004 at 10:47:54AM -0700, Nate Lawson wrote:
> > The ACPI CA core subsystem does NOT scan for particular devices (via the
> > _HID, _UID, etc.)  The upper OSPM software already does this and is thus
> > responsible for enabling individual devices and GPEs for wake-up,
> > including the power button, lid button, etc.  This code apparently still
> > needs to be written.
> 
> You mean like this code snippet?

Having such a code snippet is definitely needed: without it, no wakeup GPEs
are enabled in Linux, thus causing too much trouble...

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fix wake GPE enabling

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Thu, Apr 08, 2004 at 09:43:07AM -0700, Moore, Robert wrote:
> > However, the ACPI subsystem, and I do not care whether it is the CA
> core
> > or
> > any other part, currently does not enable any(!) wake GPEs.
> > 
> 
> Linux needs a user interface and some additional OSPM software to
> identify and program the wake devices, as well as handle the other
> information in the _PRW methods.
> 
> The ACPI CA core subsystem will only identify wake vs. runtime GPEs.

OK, as long as it gets into Linux, I do not care whether its the ACPI CA or
the ACPI OSPM part. It just seemed to me that the ACPI CA were the place to
do it, but as its contrary to spec I'll only use it on my own notebook [so
that it wakes up from sleep] until a proper patch / proper code in Linux
drivers/acpi/* exists.

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Fix wake GPE enabling

[Nate Lawson]

It's cut/pasted from FreeBSD, been around since July 2002 and tested as
working.

-Nate

On Thu, 8 Apr 2004, Moore, Robert wrote:
> Nate,
>
> Yes, the code below looks good.  This is the model that we have in mind
> for the ACPI CA code, OSPM, and individual drivers.
>
> Bob
>
>
> > -----Original Message-----
> > From: Nate Lawson [mailto:nate-Y6VGUYTwhu0@public.gmane.org]
> > Sent: Thursday, April 08, 2004 10:48 AM
> > To: Moore, Robert
> > Cc: Dominik Brodowski; Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org;
> > Grover, Andrew
> > Subject: RE: [ACPI] Fix wake GPE enabling
> >
> > On Thu, 8 Apr 2004, Moore, Robert wrote:
> > > Linux needs a user interface and some additional OSPM software to
> > > identify and program the wake devices, as well as handle the other
> > > information in the _PRW methods.
> > >
> > > The ACPI CA core subsystem will only identify wake vs. runtime GPEs.
> > >
> > > > -> wake_enable is not touched directly,
> > > > -> events/evgpeblk.c does not care, and according to your opinion,
> > > should
> > > >    not care.
> > > > -> acpi_enable_gpe is _only_ called by drivers/acpi/ec.c, which
> means
> > > it
> > > > is
> > > >    _not_ called for buttons, which are very clearly needed in most
> > > cases
> > > > to
> > > >    wake up a system.
> > > >
> > > > At least for buttons, the ACPI subsystem should enable their wake
> > > > functionality, e.g. the wake GPEs, unconditionally. Having to
> manually
> > > > enter
> > > > "echo powerbutton > /proc/acpi/wakeup_devices", as the patch in
> bug
> > > #1415
> > > > suggests, seems to be overly complicated. However, having this
> file as
> > > > override might be a valid option, I agree.
> > > >
> > >
> > > The ACPI CA core subsystem does NOT scan for particular devices (via
> the
> > > _HID, _UID, etc.)  The upper OSPM software already does this and is
> thus
> > > responsible for enabling individual devices and GPEs for wake-up,
> > > including the power button, lid button, etc.  This code apparently
> still
> > > needs to be written.
> >
> > You mean like this code snippet?
> >
> > -Nate
> >
> > acpi_button_attach(device_t dev)
> > {
> >     if (sc->fixed) {
> >         AcpiClearEvent(event);
> >         status = AcpiInstallFixedEventHandler(event,
> >                         acpi_button_fixed_handler, sc);
> >     } else {
> >         status = AcpiInstallNotifyHandler(sc->button_handle,
> >                         ACPI_DEVICE_NOTIFY,
> acpi_button_notify_handler,
> > sc);
> >     }
> >
> >     acpi_device_enable_wake_capability(sc->button_handle, 1);
> > }
> >
> > acpi_button_suspend(device_t dev)
> > {
> >     struct acpi_button_softc    *sc;
> >
> >     sc = device_get_softc(dev);
> >     acpi_device_enable_wake_event(sc->button_handle);
> >     return (0);
> > }
> >
> > acpi_device_enable_wake_capability(ACPI_HANDLE h, int enable)
> > {
> >     /*
> >      * All Power Resources referenced by elements 2 through N
> >      * of the _PRW object are put into the ON state.
> >      */
> >
> >     (void)acpi_SetInteger(h, "_PSW", enable);
> > }
> >
> > acpi_device_enable_wake_event(ACPI_HANDLE h)
> > {
> >     status = AcpiEvaluateObject(h, "_PRW", NULL, &prw_buffer);
> >     if (ACPI_FAILURE(status))
> >         return;
> >
> >     switch (res->Package.Elements[0].Type) {
> >     case ACPI_TYPE_INTEGER:
> >         /*
> >          * If the data type of this package element is numeric, then
> this
> >          * _PRW package element is the bit index in the GPEx_EN, in
> the
> >          * GPE blocks described in the FADT, of the enable bit that is
> >          * enabled for the wake event.
> >          */
> >         status = AcpiEnableGpe(NULL, res-
> > >Package.Elements[0].Integer.Value,
> >                                ACPI_EVENT_WAKE_ENABLE);
> > }
>


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Fix wake GPE enabling

[Masanori Kanaoka]

[-- Attachment #1: Type: Text/Plain, Size: 1774 bytes --]

Hi

       From: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
    Subject: RE: [ACPI] Fix wake GPE enabling
      Date : Thu, 08 Apr 2004 09:32:35 -0700
 Message-ID: <37F890616C995246BE76B3E6B2DBE0554F1A3B-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>

$ Found something in the ACPI Specification:

$ Section 5.6.2.2.1, "Wake Events" (Under "General-Purpose Event Handling)

$ "Events that wake may not be intermixed with non-wake events on the same
$ GPE input. Also, all wake events not exclusively tied to a GPE input
$ (for example, one input is shared for multiple wake events) need to have
$ individual enable and status bits in order to properly handle the
$ semantics used by the system."

$ Bob

I found same section in ACPI-2.0a.pdf(20020331).

On My TOSHIBA Libretto L3, 
  - _GPE has two Methods(_L09 and _L1A).
  - USB1,ASND,LAN_ and CBC0 have _PWR that a first element is 0x09.
  - _LID has _PWR that a first element is 0x1A.
  - _GPE notify some devices(include _LID) via _L1A.

Is it broken?
TOSHIBA Libretto L1, L2 seem same.

You can find My LibrettoL3.asl and .dsdt file at:
  http://www.ann.hi-ho.ne.jp/~kanaoka/librettoL3.{asl,dsdt}

and also find LibrettoL1/L2's file at:
  http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L1-060TNMM.asl?cvsroot=freebsd-jp
  http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L1-060TNMM.dsdt?cvsroot=freebsd-jp
  http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L2-060TNML.asl?cvsroot=freebsd-jp
  http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L2-060TNML.dsdt?cvsroot=freebsd-jp

If it is broken, How can I avoid this problem ?
Any suggestions ?

Best Regards
---
 Masanori Kanaoka	kanaoka-Y4eNCM2L5QUzdwRXePBTQw@public.gmane.org


[-- Attachment #2: Type: application/pgp-signature, Size: 478 bytes --]

RE: Fix wake GPE enabling

[Moore, Robert]

GPE 09 with _L09 looks OK, it is clearly a wake GPE (because all the
Notify statements within it are of the form Notify(XXXX, 2) -- 2 means
"wake".

GPE 1A appears to be a runtime GPE, therefore the _PWR method under _LID
looks suspicious.

Bob


> -----Original Message-----
> From: Masanori Kanaoka [mailto:kanaoka-Y4eNCM2L5QUzdwRXePBTQw@public.gmane.org]
> Sent: Friday, April 09, 2004 3:11 AM
> To: Moore, Robert
> Cc: kochi-S783fYmB3Ccdnm+yROfE0A@public.gmane.org; linux@dominikbrodowski.de; Brown, Len; acpi-
> devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Grover, Andrew
> Subject: Re: [ACPI] Fix wake GPE enabling
> 
> Hi
> 
>        From: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>     Subject: RE: [ACPI] Fix wake GPE enabling
>       Date : Thu, 08 Apr 2004 09:32:35 -0700
>  Message-ID:
> <37F890616C995246BE76B3E6B2DBE0554F1A3B-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
> 
> $ Found something in the ACPI Specification:
> 
> $ Section 5.6.2.2.1, "Wake Events" (Under "General-Purpose Event
Handling)
> 
> $ "Events that wake may not be intermixed with non-wake events on the
same
> $ GPE input. Also, all wake events not exclusively tied to a GPE input
> $ (for example, one input is shared for multiple wake events) need to
have
> $ individual enable and status bits in order to properly handle the
> $ semantics used by the system."
> 
> $ Bob
> 
> I found same section in ACPI-2.0a.pdf(20020331).
> 
> On My TOSHIBA Libretto L3,
>   - _GPE has two Methods(_L09 and _L1A).
>   - USB1,ASND,LAN_ and CBC0 have _PWR that a first element is 0x09.
>   - _LID has _PWR that a first element is 0x1A.
>   - _GPE notify some devices(include _LID) via _L1A.
> 
> Is it broken?
> TOSHIBA Libretto L1, L2 seem same.
> 
> You can find My LibrettoL3.asl and .dsdt file at:
>   http://www.ann.hi-ho.ne.jp/~kanaoka/librettoL3.{asl,dsdt}
> 
> and also find LibrettoL1/L2's file at:
>   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L1-
> 060TNMM.asl?cvsroot=freebsd-jp
>   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L1-
> 060TNMM.dsdt?cvsroot=freebsd-jp
>   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L2-
> 060TNML.asl?cvsroot=freebsd-jp
>   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L2-
> 060TNML.dsdt?cvsroot=freebsd-jp
> 
> If it is broken, How can I avoid this problem ?
> Any suggestions ?
> 
> Best Regards
> ---
>  Masanori Kanaoka	kanaoka-Y4eNCM2L5QUzdwRXePBTQw@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

RE: Fix wake GPE enabling

[Moore, Robert]

Actually, the LID _GPE code:

            If(\_SB_.MEM_.GP71) {
                Store(0x0, \_SB_.MEM_.GP71)
                Notify(\_SB_.LID_, 0x80)

Looks similar to the example in the ACPI spec, which (in addition to the
"Control Method Power Button") seems to show the use of GPEs as both
wake and runtime events.

Something very fishy here.

I am consulting with the ACPI specification gurus.

Bob


> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
> admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Moore, Robert
> Sent: Friday, April 09, 2004 9:57 AM
> To: Masanori Kanaoka
> Cc: kochi-S783fYmB3Ccdnm+yROfE0A@public.gmane.org; linux@dominikbrodowski.de; Brown, Len; acpi-
> devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Grover, Andrew
> Subject: RE: [ACPI] Fix wake GPE enabling
> 
> GPE 09 with _L09 looks OK, it is clearly a wake GPE (because all the
> Notify statements within it are of the form Notify(XXXX, 2) -- 2 means
> "wake".
> 
> GPE 1A appears to be a runtime GPE, therefore the _PWR method under
_LID
> looks suspicious.
> 
> Bob
> 
> 
> > -----Original Message-----
> > From: Masanori Kanaoka [mailto:kanaoka-Y4eNCM2L5QUzdwRXePBTQw@public.gmane.org]
> > Sent: Friday, April 09, 2004 3:11 AM
> > To: Moore, Robert
> > Cc: kochi-S783fYmB3Ccdnm+yROfE0A@public.gmane.org; linux@dominikbrodowski.de; Brown, Len; acpi-
> > devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Grover, Andrew
> > Subject: Re: [ACPI] Fix wake GPE enabling
> >
> > Hi
> >
> >        From: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >     Subject: RE: [ACPI] Fix wake GPE enabling
> >       Date : Thu, 08 Apr 2004 09:32:35 -0700
> >  Message-ID:
> >
<37F890616C995246BE76B3E6B2DBE0554F1A3B-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
> >
> > $ Found something in the ACPI Specification:
> >
> > $ Section 5.6.2.2.1, "Wake Events" (Under "General-Purpose Event
> Handling)
> >
> > $ "Events that wake may not be intermixed with non-wake events on
the
> same
> > $ GPE input. Also, all wake events not exclusively tied to a GPE
input
> > $ (for example, one input is shared for multiple wake events) need
to
> have
> > $ individual enable and status bits in order to properly handle the
> > $ semantics used by the system."
> >
> > $ Bob
> >
> > I found same section in ACPI-2.0a.pdf(20020331).
> >
> > On My TOSHIBA Libretto L3,
> >   - _GPE has two Methods(_L09 and _L1A).
> >   - USB1,ASND,LAN_ and CBC0 have _PWR that a first element is 0x09.
> >   - _LID has _PWR that a first element is 0x1A.
> >   - _GPE notify some devices(include _LID) via _L1A.
> >
> > Is it broken?
> > TOSHIBA Libretto L1, L2 seem same.
> >
> > You can find My LibrettoL3.asl and .dsdt file at:
> >   http://www.ann.hi-ho.ne.jp/~kanaoka/librettoL3.{asl,dsdt}
> >
> > and also find LibrettoL1/L2's file at:
> >   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L1-
> > 060TNMM.asl?cvsroot=freebsd-jp
> >   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L1-
> > 060TNMM.dsdt?cvsroot=freebsd-jp
> >   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L2-
> > 060TNML.asl?cvsroot=freebsd-jp
> >   http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Libretto-L2-
> > 060TNML.dsdt?cvsroot=freebsd-jp
> >
> > If it is broken, How can I avoid this problem ?
> > Any suggestions ?
> >
> > Best Regards
> > ---
> >  Masanori Kanaoka	kanaoka-Y4eNCM2L5QUzdwRXePBTQw@public.gmane.org
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=ick
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click

Re: Fix wake GPE enabling

[Masanori Kanaoka]

[-- Attachment #1: Type: Text/Plain, Size: 889 bytes --]

Hi,

       From: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
    Subject: RE: [ACPI] Fix wake GPE enabling
      Date : Fri, 09 Apr 2004 09:57:01 -0700
 Message-ID: <37F890616C995246BE76B3E6B2DBE0554F207E-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>

$ GPE 09 with _L09 looks OK, it is clearly a wake GPE (because all the
$ Notify statements within it are of the form Notify(XXXX, 2) -- 2 means
$ "wake".

$ GPE 1A appears to be a runtime GPE, therefore the _PWR method under _LID
$ looks suspicious.

Thank you for detailed explanation.
I see this. 

So with acpica 20040326 or later, GPE does not enabled on My libretto L3.
I set FLASE to AcpiGbl_LeaveWakeGpesDisabled to avoid this problem.

I don't know whether it is right way or not.
Any suggestions?

Best Regards.
---
 Masanori Kanaoka	kanaoka-Y4eNCM2L5QUzdwRXePBTQw@public.gmane.org



[-- Attachment #2: Type: application/pgp-signature, Size: 478 bytes --]

Re: Fix wake GPE enabling

[Pavel Machek]

Hi!

> > > However, the ACPI subsystem, and I do not care whether it is the CA
> > core
> > > or
> > > any other part, currently does not enable any(!) wake GPEs.
> > > 
> > 
> > Linux needs a user interface and some additional OSPM software to
> > identify and program the wake devices, as well as handle the other
> > information in the _PRW methods.
> > 
> > The ACPI CA core subsystem will only identify wake vs. runtime GPEs.
> 
> OK, as long as it gets into Linux, I do not care whether its the ACPI CA or
> the ACPI OSPM part. It just seemed to me that the ACPI CA were the place to
> do it, but as its contrary to spec I'll only use it on my own notebook [so
> that it wakes up from sleep] until a proper patch / proper code in Linux
> drivers/acpi/* exists.

If upper layers do not exist, it is right thing to do some minimal
default in low layer. Do not give that patch up so quickly ;-).

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click