Eric Benton wrote:
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?
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
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
