qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation
Date: Wed, 12 Nov 2014 14:59:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0


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.

> 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.

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.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]