Messages in this thread |  | | | Date | Tue, 23 Jun 2009 17:33:59 -0400 (EDT) | | From | Len Brown <> | | Subject | Re: [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support |
| |
On Tue, 23 Jun 2009, Matthew Garrett wrote:
> On Tue, Jun 23, 2009 at 04:00:55PM -0400, Len Brown wrote: > > > But given that the hardware is fixed (it was fixed over a year ago), > > the question becomes what does ACPI mean on such a platform? > > It turns out that if you look at the ACPI spec and delete all the > > things that could not possibly apply to MRST, then you are left > > with very little. > > Right, but instead you've effectively taken ACPI, done s/XSDT/SYST/ and > then only supported a subset of the static tables and added some others.
sfi_acpi_table_parse(ACPI_SIG_MCFG, NULL, NULL, 0, pci_parse_mcfg);
is used today to provide access to a standard PCI-SIG-defined ACPI-wrapped static MMCONFIG table via a standard ACPI XSDT.
No, this doesn't mean that the platform firmware supports ACPI mode. The XSDT simply keeps the SFI table name space from conflicting with the ACPI table name-space.
If there is a need to access another ACPI defined/reserved signature table, the same mechanism can be used -- just fill in the signature and the routine to parse the table.
> In return we gain two implementations to debug. I'm absolutely fine with > the concept of a cut-down ACPI, but I'm pretty uncomfortable with it > being implemented as a single-vendor spec. Right now SFI's a > reimplementation of functionality we already have for the benefit of a > single chipset, whereas instead it could have been a refactoring of the > ACPI codebase to allow vendors to include whatever subset of the ACPI > functionality they felt necessary.
It is a fact that the list of things that SFI could have been, and the list of things that SFI is not, are _both_ much larger than the list of things it is.
cheers, -Len Brown, Intel Open Source Technology Center
|  |