Hi Alex, Thank you! It finally begins to settle down for me. On 11/27/06, Alexey Starikovskiy <alexey.y.starikovskiy@xxxxxxxxxxxxxxx> 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. - 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
