Re: How ACPI is actually implemented?

[Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>]

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.