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@xxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
