On 12/11/2014 15:10, Mark Rutland wrote: >>> We can't just pick-and-mix >>> portions of ACPI and state that it's specified and standard. >> >> But that's what you already do if you want to build ACPI tables from DT. >> You are already picking-and-mixing the variable portions of the ACPI >> tables and make a DT bindings for them. > > I don't follow. I argued _against_ trying to build ACPI tables from DT > because the two don't quite match up anyway. I argued _against_ trying > to convert ACPI tables to DT in prior discussions for similar reasons.
Sorry, that was not you-Mark, but more you-ARM. And in fact I'd tend to agree with you, but if there are people that want not to use ACPI or UEFI or both, I think it's better if the UEFI firmware swallows the same pill and builds ACPI from DT. > In addition to fixing up the other specs which are affected by this > (e.g. how we describe those additional CPUs). There's also some > de-ACPIing to be done in addition to de-x86ification, and we need to be > careful to ensure we have access to all the information we require in > the absence of ACPI, and that we have a well defined behaviour on both > sides of the interface for what would previously have been implicit in > ACPI. Yes, I agree. On the QEMU side the de-ACPIfication would have to be done anyway (no GPE because of the reduced hardware), but you need extra de-ACPIfication for stuff like the SRAT. > I'm not saying that this is impossible. It's just a greater body of work > than modifying one spec. No doubt about that. Paolo
