Re: How ACPI is actually implemented?

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

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