From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoYdw-0006SV-K3 for qemu-devel@nongnu.org; Wed, 12 Nov 2014 09:11:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoYdq-00004w-C2 for qemu-devel@nongnu.org; Wed, 12 Nov 2014 09:11:32 -0500 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:42316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoYdq-0008U0-2h for qemu-devel@nongnu.org; Wed, 12 Nov 2014 09:11:26 -0500 Date: Wed, 12 Nov 2014 14:10:59 +0000 From: Mark Rutland Message-ID: <20141112141059.GH28015@leverpostej> References: <1414691045-4793-1-git-send-email-a.spyridakis@virtualopensystems.com> <546323A7.6040805@huawei.com> <20141112105640.GB28015@leverpostej> <1857764.BysEu3dgOQ@wuerfel> <20141112113401.GH19598@cbox> <5463490B.9080101@redhat.com> <20141112121809.GF28015@leverpostej> <54635222.5000700@redhat.com> <20141112134104.GG28015@leverpostej> <546367C2.3000603@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546367C2.3000603@redhat.com> Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Arnd Bergmann , "linaro-acpi@lists.linaro.org" , Paul Mundt , Claudio Fontana , QEMU Developers , Jani Kokkonen , "tech@virtualopensystems.com" , Christoffer Dall 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.