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? 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. - 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
