Hi All,
On 11/28/06, Wu, Cody <[EMAIL PROTECTED]> wrote:
Hi Kein,
>The SCI handler, which will run a GPE handler as you said here, Who is
>belongs to? I mean, is it part of OS? Or BIOS? ACPI spec seems says if
>the OS is ACPI compatible and ACPI was enabled, EC will trigger SCI,
>then handled by OS otherwise it will trigger SMI which handled by BIOS,
>is this true?
GPE handler is provided by Bios originally in the form of AML. Os's AcPI
driver will parse it and link it to SCI interrupt processing. Whether EC
will trigger SCI or SMI depends on how you want it to be done as well as
what OS you are working with. For OS supporting ACPI it will enable ACPI
controller on the chipset and SCI will take precedence over SMI.
If we will go back again to the GPEs, In my DSDT (Lenovo Laptop),
under the _GPE scope, there is a method that assigns itself to the 3rd
bit of the GPE register block. It's code is the following:
Method (_L03, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB1, 0x02)
}
Now, it tells the OSPM to notify the native device driver of the USB1
device to Wake (0x02). But, the thing is, I didn't see in any place
that the actual USB1 device is being associated with the 3rd bit of
this GPE register block. Is it defined in some other ACPI table or is
it dectated by the system platform?
Thanks,
Eric.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
