How ACPI is actually implemented?

How ACPI is actually implemented?

[Eric Benton]

Hi,

I'm trying to figure out how ACPI is implemented, I don't know if this
list is the right one to ask but I'm sure there are kind people in
this place that will help me in my quest :)
I tried to look for resources but I couldn't find too many. I'm
interested to know how ACPI works in the hardware level... so, after a
lot of reading I left with these questions, any knowledge provided is
greatly appreciated.

By looking at /proc/irq and /proc/ioports I can see that ACPI is
allocated with IRQ9 and I/O ports 0x400-0x42F.
1. How does exactly a hardware device generates an event?
2. How does the OS asks a device to change it's state? what *exactly* happens?

I read that the BIOS supplies all the ACPI tables.
3. Are they are being built in compile time (this is what I understand
from the FAQ at Intel's website)?
4. What happens If a new PCI device is being added to the system, how
the DSDT is being updated? (If at all...)

I saw a note about an ACPI Controller.
5. What exactly is the role of this controller? How it operates? And who
6. In general, I'm looking to find out what is the role (in respect to
"talking with the hardware") of these entities: the driver, the
device, the OS (including the CA)? Who reads/writes to the I/O ports.
Who sets the IRQ? the controller? or is it the device itself? What
happens exactly?

I tried reading the ACPI spec, but it's 600+ pages that doesn't answer
these questions...

Thanks in advance,
Eric.

Re: How ACPI is actually implemented?

[Len Brown]

On Sunday 26 November 2006 12:35, Eric Benton wrote:
> Hi,
> 
> I'm trying to figure out how ACPI is implemented, I don't know if this
> list is the right one to ask but I'm sure there are kind people in
> this place that will help me in my quest :)
> I tried to look for resources but I couldn't find too many. I'm
> interested to know how ACPI works in the hardware level... so, after a
> lot of reading I left with these questions, any knowledge provided is
> greatly appreciated.
> 
> By looking at /proc/irq and /proc/ioports I can see that ACPI is
> allocated with IRQ9 and I/O ports 0x400-0x42F.
> 1. How does exactly a hardware device generates an event?

Depends on the hardware device.
ACPI interrupts come in through the SCI -- System Control Interrupt,
aka the ACPI interrupt, as seen in /proc/interrupts.  But many events
can cause an SCI.  In particular, there is another level of interrupt
fan-out below the SCI called  a General Purpose Event (GPE) which
can have many sources.

> 2. How does the OS asks a device to change it's state? what *exactly* happens?

Not sure I understand the question.  Are you asking how an interrupt
is processed?  It comes in like a PCI interrupt, and depending on the
cause it is serviced differently.

eg. the SCI handler might run a GPE handler, which will run the _Lxx
method in AML, which might send a Notify() to an AML device object.
The OS might have registered a driver on that object which
will receive the event and do some action, such as sending an event
to user-space.  see button.c for an even simpler example.
 
> I read that the BIOS supplies all the ACPI tables.
> 3. Are they are being built in compile time (this is what I understand
> from the FAQ at Intel's website)?

the ACPI tables are built by the OEM and with an ASL->AML compiler
and are burned into the BIOS.

> 4. What happens If a new PCI device is being added to the system, how
> the DSDT is being updated? (If at all...)

The DSDT is static -- it is never updated.  However, it can be augmented by loading
an SSDT, or the AML can use the Load() operator to add additional code
at run-time.
 
> I saw a note about an ACPI Controller.
> 5. What exactly is the role of this controller? How it operates? And who
> 6. In general, I'm looking to find out what is the role (in respect to
> "talking with the hardware") of these entities: the driver, the
> device, the OS (including the CA)? Who reads/writes to the I/O ports.
> Who sets the IRQ? the controller? or is it the device itself? What
> happens exactly?

The platform dictates which IRQ is used for ACPI.  The OS generally
doesn't get to choose this.
IO ports can be read and written by the BIOS, by the BIOS AML
which is run on the BIOS' behalf by the OS AML interpreter,
or by the OS.
 
> I tried reading the ACPI spec, but it's 600+ pages that doesn't answer
> these questions...

read it a  couple of times, actually it does:-)
There is also a book called "Building the Power Efficient PC" from Intel Press
which might help you.

It would help if you could ask the most specific question possible,
as it is difficult to answer extremely open-ended questions
without writing a book.

-Len

Re: How ACPI is actually implemented?

[Eric Benton]

Hi Len,

Thanks for the replay, I really appreciate it, but things are still
not so clear to me :)
I'll try to be more specific... My goal is to learn ACPI and write an
article about it.

On 11/27/06, Len Brown <len.brown@intel.com> wrote:
> On Sunday 26 November 2006 12:35, Eric Benton wrote:
> > Hi,
> >
> > I'm trying to figure out how ACPI is implemented, I don't know if this
> > list is the right one to ask but I'm sure there are kind people in
> > this place that will help me in my quest :)
> > I tried to look for resources but I couldn't find too many. I'm
> > interested to know how ACPI works in the hardware level... so, after a
> > lot of reading I left with these questions, any knowledge provided is
> > greatly appreciated.
> >
> > By looking at /proc/irq and /proc/ioports I can see that ACPI is
> > allocated with IRQ9 and I/O ports 0x400-0x42F.
> > 1. How does exactly a hardware device generates an event?
>
> Depends on the hardware device.
> ACPI interrupts come in through the SCI -- System Control Interrupt,
> aka the ACPI interrupt, as seen in /proc/interrupts.  But many events
> can cause an SCI.  In particular, there is another level of interrupt
> fan-out below the SCI called  a General Purpose Event (GPE) which
> can have many sources.
>

I saw that events is generated by register blocks (control/status),
which can be accessed through the FADT. What exactly are those
register blocks? memory mapped I/O? or PIO? Does the FADT is being
burnt into the BIOS as well?

1 .Ok, so the OS/BIOS can turn on the enable bit and if the status bit
is set by the device, a SCI is generated. Two of those GPE registers
block are fixed in the FADT (The GPE0_BLK or the GPE1_BLK), can it be
extended? who would want to add a GPE register block? a device or the
OS/BIOS? How does a device is being allocated with the corresponding
GPE bits? Is it through the DSDT?

2. After the SCI is issued, how does the OS (or BIOS?) determines what
device caused the event? Does a GPE handler have to walk through the
ACPI "tables" or is it associated with the exact device that it's
suppose to handle? (or device specific handlers are being managed
internally by the OS?) How would you define a GPE handler?


> The DSDT is static -- it is never updated.  However, it can be augmented by loading
> an SSDT, or the AML can use the Load() operator to add additional code
> at run-time.
>

How does that happens exactly?

> > I saw a note about an ACPI Controller.
> > 5. What exactly is the role of this controller? How it operates? And who
> > 6. In general, I'm looking to find out what is the role (in respect to
> > "talking with the hardware") of these entities: the driver, the
> > device, the OS (including the CA)? Who reads/writes to the I/O ports.
> > Who sets the IRQ? the controller? or is it the device itself? What
> > happens exactly?
>
> The platform dictates which IRQ is used for ACPI.  The OS generally
> doesn't get to choose this.
> IO ports can be read and written by the BIOS, by the BIOS AML
> which is run on the BIOS' behalf by the OS AML interpreter,
> or by the OS.

In practice, who reads and writes to the I/O ports, and for what purposes?


>
> > I tried reading the ACPI spec, but it's 600+ pages that doesn't answer
> > these questions...
>
> read it a  couple of times, actually it does:-)
> There is also a book called "Building the Power Efficient PC" from Intel Press
> which might help you.
>
> It would help if you could ask the most specific question possible,
> as it is difficult to answer extremely open-ended questions
> without writing a book.

Yeah, ok ;-)
Can you please describe the process of what happens when you decide to
switch the graphic adapter's screen? This is a bit complicated
example, but it will really help me understanding. For example, In a
Laptop, when you decide to switch from the LCD to an external VGA
screen?
It starts by a software request... I know all the handlers are defined
in the dsdt but, a description of the process (the handlers
registering + what events are being caused by software/hardware and
how is the hardware is related to the story) will help me finally
comprehend this...

>
> -Len
>


Thanks for helping!
Eric.

Re: How ACPI is actually implemented?

[Takanori Watanabe]

In message <29545330611270227y4200182bkc9dfffbc62ab8d65@mail.gmail.com>, "Eric 
Benton" wrote:
>Yeah, ok ;-)
>Can you please describe the process of what happens when you decide to
>switch the graphic adapter's screen? This is a bit complicated
>example, but it will really help me understanding. For example, In a
>Laptop, when you decide to switch from the LCD to an external VGA
>screen?
>It starts by a software request... I know all the handlers are defined
>in the dsdt but, a description of the process (the handlers
>registering + what events are being caused by software/hardware and
>how is the hardware is related to the story) will help me finally
>comprehend this...

It's not always true. If your laptop supports video card output switching,
it is not always implemented in AML. It should be implemented by video card's 
driver, not AML bytecode. But some laptops has BIOS request to do it.
The request is invoked by SMI when some specific I/O port is accessed.
Laptop extras device entity , implemented by AML, provides some method 
to put calling paramater to BIOS and access I/O port.Though,
of cource, it is possible to access VGA card's register in AML.

And how laptop extra's hotkey works is as follows:

ACPI events are invoked by SCI. When SCI occured, appropriate interrupts
are request and deliverd to ACPI driver, and the driver interpritet 
the source of SCI.

When SCI gets GPIO event, it invokes AML methods bind to 
the event, eventually.

In the method, Notify() object may be evaluated. When it is evaluated,
ACPI driver invokes handler bounded to target of Notify() object.

The handler handles the Notify and may propagate event to user, as 
a driver of laptop extra.

I hope it may help you.

Re: How ACPI is actually implemented?

[Eric Benton]

On 11/27/06, Takanori Watanabe <takawata@init-main.com> wrote:
> In message <29545330611270227y4200182bkc9dfffbc62ab8d65@mail.gmail.com>, "Eric
> Benton" wrote:
> >Yeah, ok ;-)
> >Can you please describe the process of what happens when you decide to
> >switch the graphic adapter's screen? This is a bit complicated
> >example, but it will really help me understanding. For example, In a
> >Laptop, when you decide to switch from the LCD to an external VGA
> >screen?
> >It starts by a software request... I know all the handlers are defined
> >in the dsdt but, a description of the process (the handlers
> >registering + what events are being caused by software/hardware and
> >how is the hardware is related to the story) will help me finally
> >comprehend this...
>
> It's not always true. If your laptop supports video card output switching,
> it is not always implemented in AML. It should be implemented by video card's
> driver, not AML bytecode. But some laptops has BIOS request to do it.
> The request is invoked by SMI when some specific I/O port is accessed.
> Laptop extras device entity , implemented by AML, provides some method
> to put calling paramater to BIOS and access I/O port.Though,
> of cource, it is possible to access VGA card's register in AML.

Thanks for the replay Takanori,

I stumbled upon this URL recently
http://www.microsoft.com/whdc/device/display/mobiledisplay.mspx and so
I asked for this example...


>
> And how laptop extra's hotkey works is as follows:
>
> ACPI events are invoked by SCI. When SCI occured, appropriate interrupts
> are request and deliverd to ACPI driver, and the driver interpritet
> the source of SCI.
>
> When SCI gets GPIO event, it invokes AML methods bind to
> the event, eventually.
>
> In the method, Notify() object may be evaluated. When it is evaluated,
> ACPI driver invokes handler bounded to target of Notify() object.
>
> The handler handles the Notify and may propagate event to user, as
> a driver of laptop extra.
>
> I hope it may help you.
>

Yes, thank you for the example!
Eric.

Re: How ACPI is actually implemented?

[Alexey Starikovskiy]

Eric Benton wrote:
> Hi Len,
>
> Thanks for the replay, I really appreciate it, but things are still
> not so clear to me :)
> I'll try to be more specific... My goal is to learn ACPI and write an
> article about it.
>
> On 11/27/06, Len Brown <len.brown@intel.com> wrote:
>> On Sunday 26 November 2006 12:35, Eric Benton wrote:
>> > Hi,
>> >
>> > I'm trying to figure out how ACPI is implemented, I don't know if this
>> > list is the right one to ask but I'm sure there are kind people in
>> > this place that will help me in my quest :)
>> > I tried to look for resources but I couldn't find too many. I'm
>> > interested to know how ACPI works in the hardware level... so, after a
>> > lot of reading I left with these questions, any knowledge provided is
>> > greatly appreciated.
>> >
>> > By looking at /proc/irq and /proc/ioports I can see that ACPI is
>> > allocated with IRQ9 and I/O ports 0x400-0x42F.
>> > 1. How does exactly a hardware device generates an event?
>>
>> Depends on the hardware device.
>> ACPI interrupts come in through the SCI -- System Control Interrupt,
>> aka the ACPI interrupt, as seen in /proc/interrupts.  But many events
>> can cause an SCI.  In particular, there is another level of interrupt
>> fan-out below the SCI called  a General Purpose Event (GPE) which
>> can have many sources.
>>
>
> I saw that events is generated by register blocks (control/status),
> which can be accessed through the FADT. What exactly are those
> register blocks? memory mapped I/O? or PIO? Does the FADT is being
> burnt into the BIOS as well?
Usually they are a I/O ports.
Actually FADT comes from the BIOS first, DSDT/FACS are referenced in it.
>
> 1 .Ok, so the OS/BIOS can turn on the enable bit and if the status bit
> is set by the device, a SCI is generated. Two of those GPE registers
> block are fixed in the FADT (The GPE0_BLK or the GPE1_BLK), can it be
> extended?
Yes.
> who would want to add a GPE register block?
If you want all your events to have different number (think of pain of 
shared interrupts), then it is wise to
have 1 line for each GPE event.
> a device or the
> OS/BIOS?
It is much like the situation with interrupts. If system vendor chooses 
to save cents, he routes all interrupts using single wire and make it OS 
implementers headache to handle such a system; otherwise he defines 
single line for each possible GPE and arranges for as many register 
blocks as needed.
So, to answer your question, it is BIOS who says how many register 
blocks we will have in a system.
> How does a device is being allocated with the corresponding
> GPE bits? Is it through the DSDT?
Yes.
There are registered names in _GPE namespace, either _Lxx (level 
triggered event) or _Exx (edge triggered event), routines defined with 
such name would be called then/if xx GPE becomes signaled, and can send 
some information to ACPI device via Notify() call.
Also, some devices could have _GPE object in its description, what also 
binds it to appropriate GPE.
>
> 2. After the SCI is issued, how does the OS (or BIOS?) determines what
> device caused the event? Does a GPE handler have to walk through the
> ACPI "tables" or is it associated with the exact device that it's
> suppose to handle? (or device specific handlers are being managed
> internally by the OS?) How would you define a GPE handler?
>
See above.
>
>> The DSDT is static -- it is never updated.  However, it can be 
>> augmented by loading
>> an SSDT, or the AML can use the Load() operator to add additional code
>> at run-time.
>>
>
> How does that happens exactly?
>
For example, OS calls reseved _PDC method describing its capabalities in 
the processor power management.
Logic inside this method could choose to call a Load() operation with 
the additional methods/data in order to better match
with OS capabilities. Interpreter loads table found in the supplied 
location and maps its objects into global namespace.
>> > I saw a note about an ACPI Controller.
>> > 5. What exactly is the role of this controller? How it operates? 
>> And who
>> > 6. In general, I'm looking to find out what is the role (in respect to
>> > "talking with the hardware") of these entities: the driver, the
>> > device, the OS (including the CA)? Who reads/writes to the I/O ports.
>> > Who sets the IRQ? the controller? or is it the device itself? What
>> > happens exactly?
>>
>> The platform dictates which IRQ is used for ACPI.  The OS generally
>> doesn't get to choose this.
>> IO ports can be read and written by the BIOS, by the BIOS AML
>> which is run on the BIOS' behalf by the OS AML interpreter,
>> or by the OS.
>
> In practice, who reads and writes to the I/O ports, and for what 
> purposes?
>
There is a driver for Embedded Controller (EC), which communicates with it.
Two 1-byte wide I/O ports to access it, is the only requirement for I/O 
space from ACPI.
Most other ACPI drivers will access its devices through the writes/reads 
of appropriate EC registers (there are 256 of them).
There is a notable exception to this -- Fixed Feature drivers, who know 
how to access their devices, such as
frequency control of modern CPUs.
>
>>
>> > I tried reading the ACPI spec, but it's 600+ pages that doesn't answer
>> > these questions...
>>
>> read it a  couple of times, actually it does:-)
>> There is also a book called "Building the Power Efficient PC" from 
>> Intel Press
>> which might help you.
>>
>> It would help if you could ask the most specific question possible,
>> as it is difficult to answer extremely open-ended questions
>> without writing a book.
>
> Yeah, ok ;-)
> Can you please describe the process of what happens when you decide to
> switch the graphic adapter's screen? This is a bit complicated
> example, but it will really help me understanding. For example, In a
> Laptop, when you decide to switch from the LCD to an external VGA
> screen?
> It starts by a software request... I know all the handlers are defined
> in the dsdt but, a description of the process (the handlers
> registering + what events are being caused by software/hardware and
> how is the hardware is related to the story) will help me finally
> comprehend this...
>
This is not a good example, just because X11 people want to take contol 
over switching of displays,
just because ACPI does not have a clue of what is involved.

Lets take a fan control as a more "stable" example. There is a fan ACPI 
driver, which looks for a fan device described in
ACPI namespace (DSDT or SSDT tables loaded). The signature it looks for 
is PNP0C0B, the name of device could either be meaningful like FAN0 or 
some cryptic one like C159 of HP notebooks. Finding such a device, 
driver creates a directory under /proc/acpi/fan with the name of the 
device, and puts a file "state" in it. Reading from this file would look 
like "status: off" (D3 state), while writing a 0 (change state of device 
to D0 -- working) to it will turn it on.
Under the hood this write will probably cause evaluation of some ACPI 
methods defined under the fan device in namespace, and eventually write 
of some "magic" value into one of EC registers. EC will read this value 
and turn actual fan on.
Similar sequence of events happens for any other ACPI device, although 
sometime missing EC involvement or having control files not in 
/proc/acpi, but in /sys.

Regards,
    Alex.

Re: How ACPI is actually implemented?

[Eric Benton]

Hi Alex,
Thank you! It finally begins to settle down for me.

On 11/27/06, Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> wrote:
> Eric Benton wrote:
> > I saw that events is generated by register blocks (control/status),
> > which can be accessed through the FADT. What exactly are those
> > register blocks? memory mapped I/O? or PIO? Does the FADT is being
> > burnt into the BIOS as well?
> Usually they are a I/O ports.

So how is it reflected in the PCI configuration? (0xCF8, 0xCFC)
Does the PCI enums the EC as a seperate device or what?

> > 1 .Ok, so the OS/BIOS can turn on the enable bit and if the status bit
> > is set by the device, a SCI is generated. Two of those GPE registers
> > block are fixed in the FADT (The GPE0_BLK or the GPE1_BLK), can it be
> > extended?
> Yes.
> > who would want to add a GPE register block?
> If you want all your events to have different number (think of pain of
> shared interrupts), then it is wise to
> have 1 line for each GPE event.

What is the standard on the x86 / ia64 platforms?
And does the GPE register can hold more than one GPEs?

> So, to answer your question, it is BIOS who says how many register
> blocks we will have in a system.

Does it being read form the PCI configuration space?


> >> The DSDT is static -- it is never updated.  However, it can be
> >> augmented by loading
> >> an SSDT, or the AML can use the Load() operator to add additional code
> >> at run-time.
> >>
> >
> > How does that happens exactly?
> >
> For example, OS calls reseved _PDC method describing its capabalities in
> the processor power management.
> Logic inside this method could choose to call a Load() operation with
> the additional methods/data in order to better match
> with OS capabilities. Interpreter loads table found in the supplied
> location and maps its objects into global namespace.

Can you please explain how exactly the SSDT extension is getting
loaded when I connect a new ACPI enabled PCI device to the system?

> >> IO ports can be read and written by the BIOS, by the BIOS AML
> >> which is run on the BIOS' behalf by the OS AML interpreter,
> >> or by the OS.
> >
> > In practice, who reads and writes to the I/O ports, and for what
> > purposes?
> >
> There is a driver for Embedded Controller (EC), which communicates with it.
> Two 1-byte wide I/O ports to access it, is the only requirement for I/O
> space from ACPI.
> Most other ACPI drivers will access its devices through the writes/reads
> of appropriate EC registers (there are 256 of them).

What's that means? Does the EC is part of a PCI device or part of the
platform (shared)? What exactly are those EC registers? Device MSRs?
How an ACPI driver access them?

Sorry for my ignorance, I haven't dealt with hardware too much :-)

Thanks for your replays,
you really helped me.

Eric.

Re: How ACPI is actually implemented?

[Alexey Starikovskiy]

Eric Benton wrote:
> Hi Alex,
> Thank you! It finally begins to settle down for me.
>
> On 11/27/06, Alexey Starikovskiy 
> <alexey.y.starikovskiy@linux.intel.com> wrote:
>> Eric Benton wrote:
>> > I saw that events is generated by register blocks (control/status),
>> > which can be accessed through the FADT. What exactly are those
>> > register blocks? memory mapped I/O? or PIO? Does the FADT is being
>> > burnt into the BIOS as well?
>> Usually they are a I/O ports.
>
> So how is it reflected in the PCI configuration? (0xCF8, 0xCFC)
> Does the PCI enums the EC as a seperate device or what?
I think it is implemented like all other stuff on PC -- there are 
"legacy" devices like i8042 keyboard controller just sitting on 
particular addresses
in I/O space of the processor. It is BIOS who initializes PCI in a way 
for them to appear in the right place.
>
>> > 1 .Ok, so the OS/BIOS can turn on the enable bit and if the status bit
>> > is set by the device, a SCI is generated. Two of those GPE registers
>> > block are fixed in the FADT (The GPE0_BLK or the GPE1_BLK), can it be
>> > extended?
>> Yes.
>> > who would want to add a GPE register block?
>> If you want all your events to have different number (think of pain of
>> shared interrupts), then it is wise to
>> have 1 line for each GPE event.
>
> What is the standard on the x86 / ia64 platforms?
> And does the GPE register can hold more than one GPEs?
I have seen numbers from 5 to 30. On bigger boxes you can easily have 
hundreds.
>
>> So, to answer your question, it is BIOS who says how many register
>> blocks we will have in a system.
>
> Does it being read form the PCI configuration space?
>
ACPI reads everything from BIOS supplied tables. PCI is not involved here.
>
>> >> The DSDT is static -- it is never updated.  However, it can be
>> >> augmented by loading
>> >> an SSDT, or the AML can use the Load() operator to add additional 
>> code
>> >> at run-time.
>> >>
>> >
>> > How does that happens exactly?
>> >
>> For example, OS calls reseved _PDC method describing its capabalities in
>> the processor power management.
>> Logic inside this method could choose to call a Load() operation with
>> the additional methods/data in order to better match
>> with OS capabilities. Interpreter loads table found in the supplied
>> location and maps its objects into global namespace.
>
> Can you please explain how exactly the SSDT extension is getting
> loaded when I connect a new ACPI enabled PCI device to the system?
There is no such thing, IMHO. You can have ACPI enabled system, but not 
a device.
All ACPI information is produced by system BIOS at start-up. Then you 
add a device which is
known to this ACPI configs, ACPI drivers (hotplug) can execute something 
already known.

SGI is about to add something like the ACPI-enabled block with its 
series of SN patches,
but it is yet to be seen how they implement it.
>
>> >> IO ports can be read and written by the BIOS, by the BIOS AML
>> >> which is run on the BIOS' behalf by the OS AML interpreter,
>> >> or by the OS.
>> >
>> > In practice, who reads and writes to the I/O ports, and for what
>> > purposes?
>> >
>> There is a driver for Embedded Controller (EC), which communicates 
>> with it.
>> Two 1-byte wide I/O ports to access it, is the only requirement for I/O
>> space from ACPI.
>> Most other ACPI drivers will access its devices through the writes/reads
>> of appropriate EC registers (there are 256 of them).
>
> What's that means? Does the EC is part of a PCI device or part of the
> platform (shared)? What exactly are those EC registers? Device MSRs?
> How an ACPI driver access them?
inb()/outb().  As I described above it does not have any connection to PCI.
>
>
> Sorry for my ignorance, I haven't dealt with hardware too much :-)
>
> Thanks for your replays,
> you really helped me.
>
> Eric.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: How ACPI is actually implemented?

[Yuan, Kein]

> eg. the SCI handler might run a GPE handler, which will run the _Lxx
> method in AML, which might send a Notify() to an AML device object.
> The OS might have registered a driver on that object which
> will receive the event and do some action, such as sending an event
> to user-space.  see button.c for an even simpler example.

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?

>> I read that the BIOS supplies all the ACPI tables.
>> 3. Are they are being built in compile time (this is what I
understand
>> from the FAQ at Intel's website)?

> the ACPI tables are built by the OEM and with an ASL->AML compiler
> and are burned into the BIOS.

Does it means every time if need to verify the ASL is correct or not,
you need to build the BIOS again and program the binary to FWH?   Is
there any quicker way to do that? Or in another words, what's the normal
way/steps to debug ASL?

Thanks,

Kein

RE: How ACPI is actually implemented?

[Wu, Cody]

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.

>Does it means every time if need to verify the ASL is correct or not,
>you need to build the BIOS again and program the binary to FWH?   Is
>there any quicker way to do that? Or in another words, what's the
normal
>way/steps to debug ASL?

This is the rawest form of debugging ACPI. However, different OS may
provide different strategies to facilitate this process. I don't know
how Linux handles this but on Windows they can enable you to muck about
this with Registry and WinDbg.

Best regards,
Cody

-----Original Message-----
From: linux-acpi-owner@vger.kernel.org
[mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Yuan, Kein
Sent: Tuesday, November 28, 2006 9:08 AM
To: Len Brown; Eric Benton
Cc: linux-acpi@vger.kernel.org
Subject: RE: How ACPI is actually implemented?

> eg. the SCI handler might run a GPE handler, which will run the _Lxx
> method in AML, which might send a Notify() to an AML device object.
> The OS might have registered a driver on that object which
> will receive the event and do some action, such as sending an event
> to user-space.  see button.c for an even simpler example.

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?

>> I read that the BIOS supplies all the ACPI tables.
>> 3. Are they are being built in compile time (this is what I
understand
>> from the FAQ at Intel's website)?

> the ACPI tables are built by the OEM and with an ASL->AML compiler
> and are burned into the BIOS.

Does it means every time if need to verify the ASL is correct or not,
you need to build the BIOS again and program the binary to FWH?   Is
there any quicker way to do that? Or in another words, what's the normal
way/steps to debug ASL?

Thanks,

Kein
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How ACPI is actually implemented?

[Eric Benton]

Hi All,


On 11/28/06, Wu, Cody <cody.wu@intel.com> 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.

RE: How ACPI is actually implemented?

[Wu, Cody]

Hi Eric,
>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?

This is made stiff in the board hardware layout especially how it
connects onboard USB controller to the ACPI Chipset. You can find the
details illustrations such as which USB port is for which bit in the ICH
spec. 

Best regards,
Cody
-----Original Message-----
From: Eric Benton [mailto:benton71@gmail.com] 
Sent: Tuesday, November 28, 2006 7:37 PM
To: Wu, Cody
Cc: Yuan, Kein; Len Brown; linux-acpi@vger.kernel.org
Subject: Re: How ACPI is actually implemented?

Hi All,


On 11/28/06, Wu, Cody <cody.wu@intel.com> 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.

Re: How ACPI is actually implemented?

[Eric Benton]

Thanks Cody for your replay!
Thank you all guys!

Eric.

On 11/29/06, Wu, Cody <cody.wu@intel.com> wrote:
> Hi Eric,
> >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?
>
> This is made stiff in the board hardware layout especially how it
> connects onboard USB controller to the ACPI Chipset. You can find the
> details illustrations such as which USB port is for which bit in the ICH
> spec.

So does that means that the OSPM needs to

>
> Best regards,
> Cody
> -----Original Message-----
> From: Eric Benton [mailto:benton71@gmail.com]
> Sent: Tuesday, November 28, 2006 7:37 PM
> To: Wu, Cody
> Cc: Yuan, Kein; Len Brown; linux-acpi@vger.kernel.org
> Subject: Re: How ACPI is actually implemented?
>
> Hi All,
>
>
> On 11/28/06, Wu, Cody <cody.wu@intel.com> 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.
>