From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Starikovskiy Subject: Re: How ACPI is actually implemented? Date: Mon, 27 Nov 2006 18:08:21 +0300 Message-ID: <456AFF65.8060701@linux.intel.com> References: <29545330611260935l507b7853g8ec3bb1597a3c884@mail.gmail.com> <200611270055.40011.len.brown@intel.com> <29545330611270227y4200182bkc9dfffbc62ab8d65@mail.gmail.com> <456AC971.9020205@linux.intel.com> <29545330611270646u7e3ccb23pc6bf4e8cda47b009@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mga05.intel.com ([192.55.52.89]:59032 "EHLO fmsmga101.fm.intel.com") by vger.kernel.org with ESMTP id S1754447AbWK0PI1 (ORCPT ); Mon, 27 Nov 2006 10:08:27 -0500 In-Reply-To: <29545330611270646u7e3ccb23pc6bf4e8cda47b009@mail.gmail.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Eric Benton Cc: Len Brown , linux-acpi@vger.kernel.org Eric Benton wrote: > Hi Alex, > Thank you! It finally begins to settle down for me. > > On 11/27/06, Alexey Starikovskiy > 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