On Wed, Nov 12, 2014 at 01:59:30PM +0000, Paolo Bonzini wrote:
On 12/11/2014 14:41, Mark Rutland wrote:
Writing a binding for the partiuclar device might be trivial. How this would fit with the DT model is more complicated, and needs to be specified. As far as I can see, those documents are quite strongly tied to x86 ACPI (they talk in terms of OSPM, OST, GPE, APIC IDs).
OSPM -> replace with kernel driver OST -> used to generate events, doesn't need to be implemented in the kernel driver. Or just define the meaning based on the ACPI _OST spec. GPE -> replace with GPIO APIC ID -> replace with whatever id ARM CPUs have
I agree that we could do CPU and memory hotplug without ACPI, but we need to specify the full firmware interface for doing so, and how this interacts with the initial DTB if using DT.
The initial DTB has to expose the IDs for hotpluggable CPUs and the range for hotpluggable memory. In the ACPI case this goes in the SRAT. But none of this is insurmountable.
My only point is that it needs to be defined, not that this definition is impossible. That does trickle into a few places -- we currently have no way of defining a CPU in DT which is possible but not present, for example (the status property historically means something different per ePAPR).
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.
All that's left is to de-x86ify the existing spec (which is really easy), and to figure out a DT binding for it. It's really not unlike any other MMIO device.
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.
I'm not saying that this is impossible. It's just a greater body of work than modifying one spec.
Thanks, Mark.