Skip to contentSkip to conversation

acpi on new gateway laptops

DISCUSSION William Morgan 5 participants 16 messages Nov 12, 2003 – Dec 12, 2003 14 messages not in the archive ACPI

lore
Share & tools
lore

William Morgan

author
#0 lore raw

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:

Quoted 3 lines

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.

Signature · 8 lines
William <[email protected]>


-------------------------------------------------------
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/

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#2 lore raw

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.

Signature · 8 lines
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/

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 9 lines · 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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 9 lines

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.

Quoted 3 lines

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.

Signature · 11 lines
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/

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#6 lore raw

Hi Ducrot,

Excerpts (reformatted) from Ducrot Bruno's mail of 12 Nov 2003 (EST):

Quoted 2 lines

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,

Signature · 8 lines
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/

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 11 lines · William Morgan

Hi Ducrot,

Excerpts (reformatted) from Ducrot Bruno's mail of 12 Nov 2003 (EST):

Quoted 2 lines

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,

Signature · 4 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
drivers/acpi//acpi_ksyms.c renamed from linux-2.4.23-rc1/drivers/acpi//acpi_ksyms.c +1 -1
@@ -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) */
drivers/acpi//ec.c renamed from linux-2.4.23-rc1/drivers/acpi//ec.c +128 -25

201 lines not on this page · raw message

drivers/acpi//osl.c renamed from linux-2.4.23-rc1/drivers/acpi//osl.c +71 -41

147 lines not on this page · raw message

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#10 lore raw

Excerpts (reformatted) from Ducrot Bruno's mail of 18 Nov 2003 (EST):

Quoted 2 lines

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.

Signature · 8 lines
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/
#11 lore raw
In reply to a message not in the archive
Quoted 3 lines · William Morgan

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.

Quoted 7 lines
Quoted 3 lines

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

Quoted 11 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#14 lore raw
Quoted 14 lines · William Morgan

Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):

Quoted 7 lines

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.

Quoted 5 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#16 lore raw

Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):

Quoted 2 lines

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.

Signature · 8 lines
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#18 lore raw
Quoted 17 lines · William Morgan

Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):

Quoted 2 lines

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)
      ...
  }
Quoted 4 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#20 lore raw
Quoted 18 lines · Nate Lawson
Quoted 17 lines · William Morgan

Excerpts (reformatted) from Nate Lawson's mail of 17 Nov 2003 (EST):

Quoted 2 lines

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)
      ...
  }
Quoted 9 lines
Quoted 4 lines

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.

Signature · 11 lines
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#22 lore raw

Excerpts (reformatted) from Ducrot Bruno's mail of 18 Nov 2003 (EST):

Quoted 5 lines
Quoted 3 lines

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.

Signature · 8 lines
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/
#23 lore raw
In reply to a message not in the archive
Quoted 15 lines · Nate Lawson

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/

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44.0312081716110.5824-100000-j0XSImJ06nG869pVMd/[email protected]

#25 lore raw
Quoted 4 lines · Casey Harkins

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/

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44.0312081938000.6722-100000-j0XSImJ06nG869pVMd/[email protected]

#27 lore raw

Anybody?

Quoted 12 lines · Casey Harkins

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?

Quoted 5 lines

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/

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44.0312121109510.32380-100000-j0XSImJ06nG869pVMd/[email protected]

#29 lore raw

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.

Quoted 21 lines · Casey Harkins

Anybody?

Quoted 17 lines · Casey Harkins

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
Signature · 10 lines
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/