acpi on new gateway laptops

acpi on new gateway laptops

[William Morgan]

It looks like the Gateway support site contains nothing about the 200X
or 200XL models. Great. Do they support ACPI 1.0 or 2.0 or what? No
idea... I'm assuming ACPI 1.0.

I started looking at the ACPI spec. It contains two pages specifically
about the ECDT, pp128--129.

I don't quite understand the text of the first page:

  "This optional table provides the processor-relative, translated
  resources of an Embedded Controller. The presence of this table allows
  OSPM to provide Embedded Controller operation region space access
  before the namespace has been evaluated. If this table is not
  provided, the Embedded Controller region space will not be available
  until the Embedded Controller device in the AML namespace has been
  discovered and enumerated. The availability of the region space can be
  detected by providing a _REG method object underneath the Embedded
  Controller device."

(that's the entirety of it.)

It seems like having an ECDT is an optional feature? If that's so, then
what's the problem? Why isn't Linux simply "discovering and enumerating"
the "Embedded Controller device in the AML namespace"?

(BTW, it looks like ECDT actually stands for "Embedded Controller Boot
 Resources Table". Hm.)

The next page describes the contents of the table. Basically it involves
a bunch of deep hardware information, like "The bit assignment of the
SCI interrupt within the GPEx_STS register of a GPE block described in
the FADT that the embedded controller triggers."

It goes on to state that "ACPI 1.0 OSPM implementation will not
recognize or make use of the ECDT".

Shaohua Li said something that I didn't quite get either, in his first
response:

> The reason is BIOS of Gateway 400VTX lacks ECDT table.  And before
> initialize EC device, DSDT use ec space region when execute some ASL
> init methods. This will cause that battery can't be initializing.

So, what I *think* is happening, based on that, and on pp.203--204, is:

There's an Embedded Controller region (In the BIOS? In the DSDT?). One
cannot access a region until registering it, by calling
_REG(RegionSpace, 1). There's an exception to this, however, when using
an ECDT, which describes "controllers" (?) to access the Embedded
Controller region. If you have an ECDT you can then access this region
before registering it. So I think that's what the DSDT is doing, but
without providing an ECDT?

Re-examining the dmesg output, I *think* this makes sense.

So. This implies that rather than provide an ECDT, we can alternately
try and fix the DSDT. Since it's buggy anyways, that might conserve some
effort, and has the nice advantage of not forcing an upgrade to ACPI 2.0.
(Assuming I am ACPI 1.0 like you.)

I may send some of this to acpi-devel, if only to harass them.

-- 
William <wmorgan-xW3KcqxHEMnk1uMJSBkQmQ@public.gmane.org>


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: acpi on new gateway laptops

[William Morgan]

Heh. Didn't mean to hit send quite so fast. :)

For context, the two threads are:
http://sourceforge.net/mailarchive/message.php?msg_id=6229363 and
http://sourceforge.net/mailarchive/message.php?msg_id=6319180

In both cases /proc/battery is empty and it has been suggested that we
are missing an ECDT table and should (somehow) provide one.

For those in the know about ACPI, comments would be greatly appreciated
on these two issues:

First:

 [According to the ACPI spec] It seems like having an ECDT is an
 optional feature? If that's so, then what's the problem? Why isn't
 Linux simply "discovering and enumerating" the "Embedded Controller
 device in the AML namespace"?

Second, does this scenario make any sense:

 There's an Embedded Controller region (In the BIOS? In the DSDT?). One
 cannot access a region until registering it, by calling
 _REG(RegionSpace, 1). There's an exception to this, however, when using
 an ECDT, which describes "controllers" (?) to access the Embedded
 Controller region. If you have an ECDT you can then access this region
 before registering it. So I think that's what the DSDT is doing, but
 without providing an ECDT?

Third, would this solution work?

 Rather than provide an ECDT, we can alternately try and fix the DSDT.
 Since it's buggy anyways, that might conserve some effort, and has the
 nice advantage of not forcing an upgrade to ACPI 2.0.

Sorry for all the clutter. My thanks in advance.

-- 
William


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: Re: acpi on new gateway laptops

[Ducrot Bruno]

On Wed, Nov 12, 2003 at 06:33:28PM -0500, William Morgan wrote:
> Heh. Didn't mean to hit send quite so fast. :)
> 
> For context, the two threads are:
> http://sourceforge.net/mailarchive/message.php?msg_id=6229363 and
> http://sourceforge.net/mailarchive/message.php?msg_id=6319180
> 
> In both cases /proc/battery is empty and it has been suggested that we
> are missing an ECDT table and should (somehow) provide one.
> 
> For those in the know about ACPI, comments would be greatly appreciated
> on these two issues:
> 
> First:
> 
>  [According to the ACPI spec] It seems like having an ECDT is an
>  optional feature?

yes.  ECDT do not exist in ACPI 1.0, and ACPI 2.0 claims to be
compatible.  Then ECDT can only be optional.

>  If that's so, then what's the problem? Why isn't
>  Linux simply "discovering and enumerating" the "Embedded Controller
>  device in the AML namespace"?

because you can not use EC when _STA nor _INI.  Or if you know
already that you have an EC (but without ECDT), then you have already
executed the _STA associated to the EC.  Chick-and-egg problem.

> Second, does this scenario make any sense:
> 
>  There's an Embedded Controller region (In the BIOS? In the DSDT?). One
>  cannot access a region until registering it, by calling
>  _REG(RegionSpace, 1). There's an exception to this, however, when using
>  an ECDT, which describes "controllers" (?) to access the Embedded
>  Controller region. If you have an ECDT you can then access this region
>  before registering it. So I think that's what the DSDT is doing, but
>  without providing an ECDT?

The DSDT does nothing.  This is only a table that contain a language.
ECDT is a table, also.  It is not in DSDT.


> Third, would this solution work?
> 
>  Rather than provide an ECDT, we can alternately try and fix the DSDT.

Most of ACPI 1.0 compliant system (before ACPI 2.0) implement a _REG
method which basically make a kind of boolean.  Then you look if
that boolean is true, or false.  This have though some incorrect behaviour,
like 'discovering' at boot that there are 2 batteries fully charged
for example.  Note also that thinkpad does actually the two, and check
the \_REV  in a _INI method to see if it is a ACPI 2, or not.  Im not
sure that is a good idea from IBM.

I think that we should do a fake ECDT option.  That is
straightforward to implement anyway.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: Re: acpi on new gateway laptops

[William Morgan]

Hi Ducrot,

Excerpts (reformatted) from Ducrot Bruno's mail of 12 Nov 2003 (EST):
> I think that we should do a fake ECDT option.  That is straightforward
> to implement anyway.

I'm happy to hear you say this is straightforward, but I have no idea
how to do this.

What do I put in the fake ECDT?

Thanks,

-- 
William


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: Re: acpi on new gateway laptops

[Ducrot Bruno]

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

On Thu, Nov 13, 2003 at 12:03:33PM -0500, William Morgan wrote:
> Hi Ducrot,
> 
> Excerpts (reformatted) from Ducrot Bruno's mail of 12 Nov 2003 (EST):
> > I think that we should do a fake ECDT option.  That is straightforward
> > to implement anyway.
> 
> I'm happy to hear you say this is straightforward, but I have no idea
> how to do this.
> 
> What do I put in the fake ECDT?
> 

Well, I forgot that ECDT support is somewhat still buggy.  Here is anyway
a patch, but for 2.4.23-rc1.  It sucks like hell, though, but
it should work.  I needed to get a patch from Shaohua, but I needed
to look a little bit inside, due to compilation warnings.
Then the patch for faking an ECDT can be done.  The attachement include
both patchs.  When Shaohua work will be included in 2.4 mainstream,
I will go for a bit more cleaner patch.

I don't request this patch being in mainstream, because it is more
an hack, and need therefore to be rewrotten.

On boot, supply something like that:

ecdt_fake=0x66:0x62:5:-1:\\_SB.PCI0.PIB.EC0

where 0x66 is for the command port, 0x62, the data one,
5 is the gpe_bit number, -1 is the uid (when there is
no uid in the DSDT, then just pass -1), and the full
path to the EC (for me, it is \_SB.PCI0.PIB.EC0).

Note that the double \\, needed for lilo.  I must
admit I don't know if that's true for grub.

On lilo, I make something like that:

append="ecdt_fake=0x66:0x62:5:-1:\\_SB.PCI0.PIB.EC0"

Of course, you need at first to get the info from your DSDT at
really first.


Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

[-- Attachment #2: 10_fake_ecdt.diff --]
[-- Type: text/plain, Size: 10708 bytes --]

--- orig/linux-2.4.23-rc1/drivers/acpi//acpi_ksyms.c	2003-08-25 13:44:40.000000000 +0200
+++ linux-2.4.23-rc1/drivers/acpi//acpi_ksyms.c	2003-11-18 15:24:32.000000000 +0100
@@ -102,7 +102,7 @@
 EXPORT_SYMBOL(acpi_os_create_semaphore);
 EXPORT_SYMBOL(acpi_os_delete_semaphore);
 EXPORT_SYMBOL(acpi_os_wait_semaphore);
-
+EXPORT_SYMBOL(acpi_os_wait_events_complete);
 EXPORT_SYMBOL(acpi_os_read_pci_configuration);
 
 /* ACPI Utilities (acpi_utils.c) */
--- orig/linux-2.4.23-rc1/drivers/acpi//ec.c	2003-11-18 15:53:02.000000000 +0100
+++ linux-2.4.23-rc1/drivers/acpi//ec.c	2003-11-18 15:50:00.000000000 +0100
@@ -1,5 +1,5 @@
 /*
- *  acpi_ec.c - ACPI Embedded Controller Driver ($Revision: 36 $)
+ *  acpi_ec.c - ACPI Embedded Controller Driver ($Revision: 1.1 $)
  *
  *  Copyright (C) 2001, 2002 Andy Grover <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
  *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@@ -87,6 +87,11 @@
 /* If we find an EC via the ECDT, we need to keep a ptr to its context */
 static struct acpi_ec	*ec_ecdt;
 
+/* Fake an ECDT, if the BIOS do not provide one, but we need it though */
+static int is_ecdt_fake = 0;
+static struct acpi_ec ecdt_fake;
+static char ecdt_fake_id[255];
+
 /* External interfaces use first EC only, so remember */
 static struct acpi_device *first_ec;
 
@@ -585,12 +590,16 @@
 	   we now have the *real* EC info, so kill the makeshift one.*/
 	acpi_evaluate_integer(ec->handle, "_UID", NULL, &uid);
 	if (ec_ecdt && ec_ecdt->uid == uid) {
+		acpi_disable_gpe(NULL, ec_ecdt->gpe_bit, ACPI_NOT_ISR);
+		acpi_os_wait_events_complete(ec_ecdt);
 		acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
 			ACPI_ADR_SPACE_EC, &acpi_ec_space_handler);
 	
 		acpi_remove_gpe_handler(NULL, ec_ecdt->gpe_bit, &acpi_ec_gpe_handler);
 
-		kfree(ec_ecdt);
+		if (!is_ecdt_fake)
+			kfree(ec_ecdt);
+		ec_ecdt = NULL;
 	}
 
 	/* Get GPE bit assignment (EC events). */
@@ -747,6 +756,9 @@
 
 	ec = acpi_driver_data(device);
 
+	acpi_disable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
+	acpi_os_wait_events_complete(ec);
+
 	status = acpi_remove_address_space_handler(ec->handle,
 		ACPI_ADR_SPACE_EC, &acpi_ec_space_handler);
 	if (ACPI_FAILURE(status))
@@ -766,31 +778,38 @@
 	acpi_status		status;
 	struct acpi_table_ecdt 	*ecdt_ptr;
 
-	status = acpi_get_firmware_table("ECDT", 1, ACPI_LOGICAL_ADDRESSING, 
-		(struct acpi_table_header **) &ecdt_ptr);
-	if (ACPI_FAILURE(status))
-		return 0;
+	if (!is_ecdt_fake) {
+		status = acpi_get_firmware_table("ECDT", 1, ACPI_LOGICAL_ADDRESSING, 
+			(struct acpi_table_header **) &ecdt_ptr);
+		if (ACPI_FAILURE(status))
+			return 0;
 
-	printk(KERN_INFO PREFIX "Found ECDT\n");
+		printk(KERN_INFO PREFIX "Found ECDT\n");
 
-	 /*
-	 * Generate a temporary ec context to use until the namespace is scanned
-	 */
-	ec_ecdt = kmalloc(sizeof(struct acpi_ec), GFP_KERNEL);
-	if (!ec_ecdt)
-		return -ENOMEM;
-	memset(ec_ecdt, 0, sizeof(struct acpi_ec));
-
-	ec_ecdt->command_addr = ecdt_ptr->ec_control;
-	ec_ecdt->status_addr = ecdt_ptr->ec_control;
-	ec_ecdt->data_addr = ecdt_ptr->ec_data;
-	ec_ecdt->gpe_bit = ecdt_ptr->gpe_bit;
-	ec_ecdt->lock = SPIN_LOCK_UNLOCKED;
-	/* use the GL just to be safe */
-	ec_ecdt->global_lock = TRUE;
-	ec_ecdt->uid = ecdt_ptr->uid;
+		 /*
+		 * Generate a temporary ec context to use until the namespace is scanned
+		 */
+		ec_ecdt = kmalloc(sizeof(struct acpi_ec), GFP_KERNEL);
+		if (!ec_ecdt)
+			return -ENOMEM;
+		memset(ec_ecdt, 0, sizeof(struct acpi_ec));
+
+		ec_ecdt->command_addr = ecdt_ptr->ec_control;
+		ec_ecdt->status_addr = ecdt_ptr->ec_control;
+		ec_ecdt->data_addr = ecdt_ptr->ec_data;
+		ec_ecdt->gpe_bit = ecdt_ptr->gpe_bit;
+		ec_ecdt->lock = SPIN_LOCK_UNLOCKED;
+		/* use the GL just to be safe */
+		ec_ecdt->global_lock = TRUE;
+		ec_ecdt->uid = ecdt_ptr->uid;
+	} else {
+		if (ec_ecdt)
+			printk(KERN_INFO PREFIX "Faking ECDT\n");
+		else
+			printk(KERN_INFO PREFIX "Can't fake ECDT.  Bug?\n");
+	}
 
-	status = acpi_get_handle(NULL, ecdt_ptr->ec_id, &ec_ecdt->handle);
+	status = acpi_get_handle(NULL, is_ecdt_fake ? ecdt_fake_id : ecdt_ptr->ec_id, &ec_ecdt->handle);
 	if (ACPI_FAILURE(status)) {
 		goto error;
 	}
@@ -818,7 +837,8 @@
 
 error:
 	printk(KERN_ERR PREFIX "Could not use ECDT\n");
-	kfree(ec_ecdt);
+	if (!is_ecdt_fake)
+		kfree(ec_ecdt);
 	ec_ecdt = NULL;
 
 	return -ENODEV;
@@ -845,6 +865,89 @@
 	return_VALUE(0);
 }
 
+int __init
+acpi_fake_ecdt_setup(char *str)
+{
+	u64 control;
+	u64 data;
+	unsigned long gpe_bit;
+	unsigned long uid;
+//	char *handle;
+	struct acpi_generic_address reg;
+
+	if (!str || !*str)
+		return 0;
+
+	control = simple_strtoull(str, &str, 0);
+	if (!control || !str || *str != ':')
+		return 0;
+	str++;
+
+	data = simple_strtoull(str, &str, 0);
+	if (!data || !str || *str != ':')
+		return 0;
+	str++;
+
+	gpe_bit = simple_strtoul(str, &str, 0);
+	if (!str || *str != ':')
+		return 0;
+	str++;
+
+	/* uid made be -1 */
+	uid = simple_strtol(str, &str, 0);
+	if (!str || *str != ':')
+		return 0;
+	str++;
+
+	memset(ecdt_fake_id, 0, 255);
+	strncpy(ecdt_fake_id, str, strlen(str));
+#if 0
+	handle = kmalloc(strlen(str)+1, GFP_KERNEL);
+	if (!handle)
+		return 0;
+	strncpy(handle, str, strlen(str));
+#endif
+	// strncpy(ecdt_fake_handle, str, strlen(str));
+
+#if 0
+	ec_ecdt = kmalloc(sizeof(struct acpi_ec), GFP_KERNEL);
+	if (!ec_ecdt) {
+		kfree(handle);
+		return 0;
+	}
+#endif
+
+	ec_ecdt = &ecdt_fake;
+	memset(ec_ecdt, 0, sizeof(struct acpi_ec));
+
+	memset(&reg, 0, sizeof(reg));
+	reg.address_space_id = ACPI_ADR_SPACE_SYSTEM_IO;
+	reg.register_bit_width = 8;
+	reg.register_bit_offset = 0;
+
+	memcpy(&ec_ecdt->command_addr, &reg, sizeof(reg));
+	memcpy(&ec_ecdt->status_addr, &reg, sizeof(reg));
+	memcpy(&ec_ecdt->data_addr, &reg, sizeof(reg));
+
+	ec_ecdt->command_addr.address = control;
+	ec_ecdt->status_addr.address = control;
+	ec_ecdt->data_addr.address = data;
+	ec_ecdt->gpe_bit = gpe_bit;
+	ec_ecdt->lock = SPIN_LOCK_UNLOCKED;
+	/* use the GL just to be safe */
+	ec_ecdt->global_lock = TRUE;
+	ec_ecdt->uid = uid;
+	// ec_ecdt->handle = handle;
+
+	is_ecdt_fake = 1;
+
+	return 1;
+
+}
+
+__setup("ecdt_fake=", acpi_fake_ecdt_setup);
+
+
 /* EC can't be unloaded atm, so don't compile these */
 #if 0
 void __exit
--- orig/linux-2.4.23-rc1/drivers/acpi//osl.c	2003-08-25 13:44:41.000000000 +0200
+++ linux-2.4.23-rc1/drivers/acpi//osl.c	2003-11-18 15:35:27.000000000 +0100
@@ -54,6 +54,7 @@
 {
     OSD_EXECUTION_CALLBACK  function;
     void		    *context;
+    struct list_head	    next;
 };
 
 
@@ -611,25 +612,36 @@
 
 #endif /*CONFIG_ACPI_PCI*/
 
-static void
-acpi_os_execute_deferred (
-	void *context)
-{
-	struct acpi_os_dpc	*dpc = NULL;
-
-	ACPI_FUNCTION_TRACE ("os_execute_deferred");
-
-	dpc = (struct acpi_os_dpc *) context;
-	if (!dpc) {
-		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Invalid (NULL) context.\n"));
-		return_VOID;
+/*
+ * ACPI use kernel thread to handle SCI interrupt. Every SCI interrupt will add 
+ * a new entry in the acpi events queue. And keventd will execute the queue.The 
+ * purpose to implement the new queue is to provide a mechanism in which we can
+ * wait for completing SCI interrupt handling. In this way, before EC replaced 
+ * ECDT, it can guarantee all SCI interrupts with ECDT as its context complete.
+ */
+static LIST_HEAD(acpi_events_list);
+static spinlock_t acpi_events_list_spinlock = SPIN_LOCK_UNLOCKED;
+static struct tq_struct	task;
+static int		first_acpi_event = 1;
+
+static void 
+do_acpi_task_queue(void *dummy)
+{
+	struct list_head 	*p;
+	struct acpi_os_dpc 	*dpc;
+	unsigned long 		flags = 0;
+
+   	spin_lock_irqsave(&acpi_events_list_spinlock, flags);	
+	while (!list_empty(&acpi_events_list)) {
+		p = acpi_events_list.next;		/* get first item */
+		dpc = (struct acpi_os_dpc *)list_entry(p, struct acpi_os_dpc, next);
+		list_del(p);
+		spin_unlock_irqrestore(&acpi_events_list_spinlock, flags);
+		dpc->function(dpc->context);
+		kfree(dpc);
+		spin_lock_irqsave(&acpi_events_list_spinlock, flags);
 	}
-
-	dpc->function(dpc->context);
-
-	kfree(dpc);
-
-	return_VOID;
+	spin_unlock_irqrestore(&acpi_events_list_spinlock, flags);
 }
 
 acpi_status
@@ -639,45 +651,63 @@
 	void			*context)
 {
 	acpi_status 		status = AE_OK;
-	struct acpi_os_dpc	*dpc = NULL;
-	struct tq_struct	*task;
+	struct acpi_os_dpc	*dpc;
 
-	ACPI_FUNCTION_TRACE ("os_queue_for_execution");
+	ACPI_FUNCTION_TRACE ("acpi_os_queue_for_execution");
 
 	ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "Scheduling function [%p(%p)] for deferred execution.\n", function, context));
 
 	if (!function)
 		return_ACPI_STATUS (AE_BAD_PARAMETER);
-
-	/*
-	 * Allocate/initialize DPC structure.  Note that this memory will be
-	 * freed by the callee.  The kernel handles the tq_struct list  in a
-	 * way that allows us to also free its memory inside the callee.
-	 * Because we may want to schedule several tasks with different
-	 * parameters we can't use the approach some kernel code uses of
-	 * having a static tq_struct.
-	 * We can save time and code by allocating the DPC and tq_structs
-	 * from the same memory.
-	 */
-	dpc = kmalloc(sizeof(struct acpi_os_dpc)+sizeof(struct tq_struct), GFP_ATOMIC);
+	dpc = kmalloc(sizeof(struct acpi_os_dpc), GFP_ATOMIC);
 	if (!dpc)
 		return_ACPI_STATUS (AE_NO_MEMORY);
 
 	dpc->function = function;
 	dpc->context = context;
-
-	task = (void *)(dpc+1);
-	INIT_TQUEUE(task, acpi_os_execute_deferred, (void*)dpc);
-
-	if (!schedule_task(task)) {
-		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Call to schedule_task() failed.\n"));
-		kfree(dpc);
-		status = AE_ERROR;
+	INIT_LIST_HEAD(&dpc->next);
+	
+	spin_lock(&acpi_events_list_spinlock);
+	list_add_tail(&dpc->next, &acpi_events_list);
+	if (first_acpi_event || (!task.sync)) {
+		INIT_TQUEUE(&task, do_acpi_task_queue, NULL);
+		if (!schedule_task(&task)) {
+			ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Call to schedule_work() failed.\n"));
+			kfree(dpc);
+			status = AE_ERROR;
+		}
+		first_acpi_event = 0;
 	}
+	spin_unlock(&acpi_events_list_spinlock);
 
 	return_ACPI_STATUS (status);
 }
 
+void acpi_os_wait_events_complete(
+	void * context)
+{
+	unsigned long		flags;
+	int			over = 0;
+	struct list_head * node, * next;
+
+	while (!over) {
+		over = 1;
+		spin_lock_irqsave(&acpi_events_list_spinlock, flags);
+	 	list_for_each_safe(node, next, &acpi_events_list) {
+			struct acpi_os_dpc *dpc = list_entry(node, struct acpi_os_dpc, next);
+			if (dpc->context == context) {
+				over = 0;
+				break;
+			}
+	 	}
+
+		spin_unlock_irqrestore(&acpi_events_list_spinlock, flags);
+		if (over)
+			return;
+		do_acpi_task_queue(NULL);
+	}
+}
+
 /*
  * Allocate the memory for a spinlock and initialize it.
  */

Re: Re: acpi on new gateway laptops

[William Morgan]

Excerpts (reformatted) from Ducrot Bruno's mail of 18 Nov 2003 (EST):
> Well, I forgot that ECDT support is somewhat still buggy.  Here is anyway
> a patch, but for 2.4.23-rc1.

Ducrot,

Thanks for the patch. I will try it presently.

In the mean time I've hacked up an ECDT and tried inserting it at boot time
by saying, in drivers/acpi/osl.c:

        *new_table = NULL;
        if (strncmp(existing_table->signature,"ECDT",4) != 0) {
                printk(KERN_INFO PREFIX "overriding ECDT definition\n");
                *new_table = (struct acpi_table_header *)ecdt_table;
        }

However, at boot time, I get the following in dmesg:

ACPI: overriding ECDT definition
   tbget-0292: *** Info: Table [ECDT] replaced by host OS
  tbrsdt-0227: *** Error: Invalid signature where RSDP indicates RSDT/XSDT should be located
RSDT/XSDT signature at 1F6E7D39 (1f6e7d39) is invalid

So obviously I'm doing something wrong.

The ECDT looks like this:

/*
 * ECDT table for Gateway laptops circa 2003
 * 
 * header:
 *   signature "ECDT"
 *   length: 86
 *   revision: 0x1
 *   checksum: 0x74
 *   oem_id: "mkecdt"
 *   oem_table_id: "ecdt0001"
 *   oem_revision: 0x1
 *   asl_compiler_id: "none"
 *   asl_compiler_revision: 0
 * ec_control:
 *   address_space_id: 0x1
 *   address_space_bit_width: 0x8
 *   register_bit_offset: 0
 *   reserved (should be 0): 0
 *   address: 0x66
 * ec_data:
 *   address_space_id: 0x1
 *   address_space_bit_width: 0x8
 *   register_bit_offset: 0
 *   reserved (should be 0): 0
 *   address: 0x62
 * uid: 0
 * gpe: 0x1c
 * ec_id: "\_SB_.PCI0.LPCB.H_EC"
 * compute checksum: passed
*/

unsigned char ecdt_table[]= {
	0x45, 0x43, 0x44, 0x54, 0x56, 0x00, 0x00, 0x00, 0x01, 0x74, 0x6d, 0x6b, 0x65, 0x63, 0x64, 0x74,
	0x65, 0x63, 0x64, 0x74, 0x30, 0x30, 0x30, 0x31, 0x01, 0x00, 0x00, 0x00, 0x6e, 0x6f, 0x6e, 0x65,
	0x00, 0x00, 0x00, 0x00, 0x01, 0x08, 0x00, 0x00, 0x66, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x01, 0x08, 0x00, 0x00, 0x62, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x1c, 0x5c, 0x5f, 0x53, 0x42, 0x5f, 0x2e, 0x50, 0x43, 0x49, 0x30, 0x2e, 0x4c, 0x50, 0x43, 0x42,
	0x2e, 0x48, 0x5f, 0x45, 0x43, 0x00, 
};

So maybe I'll just try your patch.

-- 
William 


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: acpi on new gateway laptops

[Nate Lawson]

On Wed, 12 Nov 2003, William Morgan wrote:
> It seems like having an ECDT is an optional feature? If that's so, then
> what's the problem? Why isn't Linux simply "discovering and enumerating"
> the "Embedded Controller device in the AML namespace"?

Yes, it's optional.

> > The reason is BIOS of Gateway 400VTX lacks ECDT table.  And before
> > initialize EC device, DSDT use ec space region when execute some ASL
> > init methods. This will cause that battery can't be initializing.
>
> So, what I *think* is happening, based on that, and on pp.203--204, is:
>
> There's an Embedded Controller region (In the BIOS? In the DSDT?). One

in the DSDT

> cannot access a region until registering it, by calling
> _REG(RegionSpace, 1). There's an exception to this, however, when using
> an ECDT, which describes "controllers" (?) to access the Embedded
> Controller region. If you have an ECDT you can then access this region
> before registering it. So I think that's what the DSDT is doing, but
> without providing an ECDT?
>
> So. This implies that rather than provide an ECDT, we can alternately
> try and fix the DSDT. Since it's buggy anyways, that might conserve some
> effort, and has the nice advantage of not forcing an upgrade to ACPI 2.0.
> (Assuming I am ACPI 1.0 like you.)

Your DSDT attempts to access regions before there is an attached EC to
service the calls to that space, yes.  So the two approaches are to
provide an ECDT or change the DSDT to not reference those spaces early in
boot.  The problem with the latter option is that those accesses may be
crucial to initializing your laptop.  So if you remove them, it may start
up in a partially initialized state.  It's probably cleaner to provide an
ECDT.

-Nate


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: acpi on new gateway laptops

[Nate Lawson]

On Mon, 17 Nov 2003, William Morgan wrote:
> Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):
> > Your DSDT attempts to access regions before there is an attached EC to
> > service the calls to that space, yes.  So the two approaches are to
> > provide an ECDT or change the DSDT to not reference those spaces early
> > in boot.  The problem with the latter option is that those accesses
> > may be crucial to initializing your laptop.  So if you remove them, it
> > may start up in a partially initialized state.  It's probably cleaner
> > to provide an ECDT.
>
> Thanks for your reply! That's the sentiment others have expressed as
> well---the easiest thing to do is provide an ECDT. Unfortunately, we're
> not really sure how to do this, and no one seems able (or willing!) to
> say.
>
> The ACPI spec describes the contents of the table, but it's not clear to
> me how, exactly, what the "processor relative address of the embedded
> controller command/status register, in generic address structure format"
> is supposed to be. How can we discover all these gory details about the
> EC?

Get the data from the DSDT.  Dump it with acpidmp, search for PNP0C09,
then write down the resources.  Mine is below:

                Device (EC)
                {
                    Name (_HID, EisaId ("PNP0C09"))
                    Name (_UID, 0x00)
                    Name (_GPE, 0x1C)
                    ...
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0062, 0x0062, 0x01, 0x01)
                        IO (Decode16, 0x0066, 0x0066, 0x01, 0x01)
                    })
                }

This corresponds to a GPE of 0x1c, control reg 0x66, data reg 0x62.  Below
is the correct ECDT for this EC:

  ECDT: Length=82, Revision=1, Checksum=5,
        OEMID=IBM, OEM Table ID=TP-1A, OEM Revision=0x1160,
        Creator ID=IBM, Creator Revision=0x1
        EC_CONTROL=0x66:0[8] (IO)
        EC_DATA=0x62:0[8] (IO)
        UID=0, GPE_BIT=0x1c
        EC_ID=\_SB.PCI0.LPC.EC

Note that I develop FreeBSD so Linux may have slightly different ways of
defining things.

-Nate


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: acpi on new gateway laptops

[William Morgan]

Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):
> Get the data from the DSDT.  Dump it with acpidmp, search for PNP0C09,
> then write down the resources.  Mine is below:

Hm, mine looks like this:

  Device(H_EC) {
      Name(_HID, 0x090cd041)
      Name(_UID, 0x1)
      Method(_CRS) {
          Name(BFFR, Buffer(0x12) {0x47, 0x1, 0x62, 0x0, 0x62, 0x0, 0x0, 0x1, 0x47, 0x1, 0x66, 0x0, 0x66, 0x0, 0x0, 0x1, 0x79, 0x0 })
          Return(BFFR)
      }
      OperationRegion(ECR_, EmbeddedControl, 0x0, 0xff)
      ...
  }

So I'm guessing that this also corresponds to control reg=0x66 and data
reg=0x62 as I see those two numbers in the buffer. So I think I should be able
to use an ECDT that's identical to yours, except the EC_ID field (which in my
case is "\_SB_.PCI0.LPCB.H_EC")....

Let me know if that doesn't seem right; otherwise, thank you very much
for the instructions.

-- 
William


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: acpi on new gateway laptops

[Nate Lawson]

On Mon, 17 Nov 2003, William Morgan wrote:
> Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):
> > Get the data from the DSDT.  Dump it with acpidmp, search for PNP0C09,
> > then write down the resources.  Mine is below:
>
> Hm, mine looks like this:
>
>   Device(H_EC) {
>       Name(_HID, 0x090cd041)
>       Name(_UID, 0x1)
>       Method(_CRS) {
>           Name(BFFR, Buffer(0x12) {0x47, 0x1, 0x62, 0x0, 0x62, 0x0, 0x0, 0x1, 0x47, 0x1, 0x66, 0x0, 0x66, 0x0, 0x0, 0x1, 0x79, 0x0 })
>           Return(BFFR)
>       }
>       OperationRegion(ECR_, EmbeddedControl, 0x0, 0xff)
>       ...
>   }
>
> So I'm guessing that this also corresponds to control reg=0x66 and data
> reg=0x62 as I see those two numbers in the buffer. So I think I should be able
> to use an ECDT that's identical to yours, except the EC_ID field (which in my
> case is "\_SB_.PCI0.LPCB.H_EC")....

Looks right but you need to get your _GPE bit also. I think it's 0x79
but you really need to parse the buffer to be sure.  There is a flag to
acpidmp to parse buffer contents.

-Nate


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: acpi on new gateway laptops

[Ducrot Bruno]

On Mon, Nov 17, 2003 at 12:07:30PM -0800, Nate Lawson wrote:
> On Mon, 17 Nov 2003, William Morgan wrote:
> > Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):
> > > Get the data from the DSDT.  Dump it with acpidmp, search for PNP0C09,
> > > then write down the resources.  Mine is below:
> >
> > Hm, mine looks like this:
> >
> >   Device(H_EC) {
> >       Name(_HID, 0x090cd041)
> >       Name(_UID, 0x1)
> >       Method(_CRS) {
> >           Name(BFFR, Buffer(0x12) {0x47, 0x1, 0x62, 0x0, 0x62, 0x0, 0x0, 0x1, 0x47, 0x1, 0x66, 0x0, 0x66, 0x0, 0x0, 0x1, 0x79, 0x0 })
> >           Return(BFFR)
> >       }
> >       OperationRegion(ECR_, EmbeddedControl, 0x0, 0xff)
> >       ...
> >   }
> >
> > So I'm guessing that this also corresponds to control reg=0x66 and data
> > reg=0x62 as I see those two numbers in the buffer. So I think I should be able
> > to use an ECDT that's identical to yours, except the EC_ID field (which in my
> > case is "\_SB_.PCI0.LPCB.H_EC")....
> 
> Looks right but you need to get your _GPE bit also. I think it's 0x79
> but you really need to parse the buffer to be sure.  There is a flag to
> acpidmp to parse buffer contents.
> 

Not in the backported version IIRC.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: acpi on new gateway laptops

[William Morgan]

Excerpts (reformatted) from Ducrot Bruno's mail of 18 Nov 2003 (EST):
> > Looks right but you need to get your _GPE bit also. I think it's 0x79
> > but you really need to parse the buffer to be sure.  There is a flag to
> > acpidmp to parse buffer contents.
> 
> Not in the backported version IIRC.

There wasn't an option to do this in the acpidmp I found, but luckily
the DSDT specified the _GPE as 0x1c a little later on.

-- 
William


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: acpi on new gateway laptops

[Casey Harkins]

On Mon, 17 Nov 2003, Nate Lawson wrote:
> Get the data from the DSDT.  Dump it with acpidmp, search for PNP0C09,
> then write down the resources.  Mine is below:
>
>                 Device (EC)
>                 {
>                     Name (_HID, EisaId ("PNP0C09"))
>                     Name (_UID, 0x00)
>                     Name (_GPE, 0x1C)
>                     ...
>                     Name (_CRS, ResourceTemplate ()
>                     {
>                         IO (Decode16, 0x0062, 0x0062, 0x01, 0x01)
>                         IO (Decode16, 0x0066, 0x0066, 0x01, 0x01)
>                     })
>                 }


As mentioned before, I'm trying to get the embedded controller working on
a Gateway 400VTX. I've dumped the DSDT but see no "Device (EC)" section,
nor does "PNP0C09"  appear in the DSDT. Does this mean this laptop has no
embedded controller?

-casey




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: acpi on new gateway laptops

[Casey Harkins]

On Mon, 8 Dec 2003, Casey Harkins wrote:
> As mentioned before, I'm trying to get the embedded controller working on
> a Gateway 400VTX. I've dumped the DSDT but see no "Device (EC)" section,
> nor does "PNP0C09"  appear in the DSDT. Does this mean this laptop has no
> embedded controller?

Oops, after a bit more investigating I see that there is a Device(H_EC)
which appears to be my embedded controller. I also see there is a line in
my dmesg output, which appears after the "Region EmbeddedControl(3) has
no handler..." error messages, that says:

     ACPI: Embedded Controller [H_EC] (gpe 29)

So, Linux appears to be detecting my Embedded Controller after it tries to
access the "Region EmbeddedControl(3)". Does this mean that the ecdt *is*
being found, but not until after Linux tried to access it? Or does the
fact that it is detected not mean that the ecdt is being read?

cat /proc/acpi/embedded_controller/H_EC/info:
   gpe bit:                 0x1d
   ports:                   0x66, 0x62
   use global lock:         no

-casey




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: acpi on new gateway laptops

[Casey Harkins]

Anybody?

On Mon, 8 Dec 2003, Casey Harkins wrote:
> Oops, after a bit more investigating I see that there is a Device(H_EC)
> which appears to be my embedded controller. I also see there is a line in
> my dmesg output, which appears after the "Region EmbeddedControl(3) has
> no handler..." error messages, that says:
>
>      ACPI: Embedded Controller [H_EC] (gpe 29)
>
> So, Linux appears to be detecting my Embedded Controller after it tries to
> access the "Region EmbeddedControl(3)". Does this mean that the ecdt *is*
> being found, but not until after Linux tried to access it? Or does the
> fact that it is detected not mean that the ecdt is being read?
>
> cat /proc/acpi/embedded_controller/H_EC/info:
>    gpe bit:                 0x1d
>    ports:                   0x66, 0x62
>    use global lock:         no
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: acpi on new gateway laptops

[Sérgio Monteiro Basto]

I have:
cat /proc/acpi/embedded_controller/EC/info
gpe bit:                 0x06
ports:                   0x66, 0x62
use global lock:         no
but no kind of lines appears in dmesg.

On Fri, 2003-12-12 at 17:11, Casey Harkins wrote:
> 
> Anybody?
> 
> On Mon, 8 Dec 2003, Casey Harkins wrote:
> > Oops, after a bit more investigating I see that there is a Device(H_EC)
> > which appears to be my embedded controller. I also see there is a line in
> > my dmesg output, which appears after the "Region EmbeddedControl(3) has
> > no handler..." error messages, that says:
> >
> >      ACPI: Embedded Controller [H_EC] (gpe 29)
> >
> > So, Linux appears to be detecting my Embedded Controller after it tries to
> > access the "Region EmbeddedControl(3)". Does this mean that the ecdt *is*
> > being found, but not until after Linux tried to access it? Or does the
> > fact that it is detected not mean that the ecdt is being read?
> >
> > cat /proc/acpi/embedded_controller/H_EC/info:
> >    gpe bit:                 0x1d
> >    ports:                   0x66, 0x62
> >    use global lock:         no
> >
 

-- 
Sérgio M B




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/