From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCH 19/19] Documentation: ACPI for ARM64 Date: Mon, 28 Jul 2014 19:37:29 +0100 Message-ID: <20140728183729.GG2576@leverpostej> References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> <5014834.k6eecMddPC@wuerfel> <20140728101229.GD24078@leverpostej> <20140728163313.GC32359@quad.lixom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20140728163313.GC32359@quad.lixom.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Olof Johansson Cc: Mark Brown , Catalin Marinas , Will Deacon , Lv Zheng , Lorenzo Pieralisi , Daniel Lezcano , Robert Moore , "linux-acpi@vger.kernel.org" , "grant.likely@linaro.org" , Leif Lindholm , Charles Garcia-Tobin , Robert Richter , Jason Cooper , Arnd Bergmann , Marc Zyngier , Liviu Dudau , "linaro-acpi-private@linaro.org" , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , "graeme.gregory@linaro.org" List-Id: linux-acpi@vger.kernel.org On Mon, Jul 28, 2014 at 05:33:13PM +0100, Olof Johansson wrote: > On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote: > > On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote: > > > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote: > > > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo wrote: > > > > > +Relationship with Device Tree > > > > > +----------------------------- > > > > > + > > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually > > > > > +exclusive with DT support at compile time. > > > > > + > > > > > +At boot time the kernel will only use one description method depending on > > > > > +parameters passed from the bootloader. > > > > > > > > Possibly overriden by kernel bootargs. And as debated for quite a > > > > while earlier this year, acpi should still default to off -- if a DT > > > > and ACPI are both passed in, DT should at this time be given priority. > > > > > > I think this would be harder to do with the way that ACPI is passed in > > > to the kernel. IIRC, you always have a minimal DT information based on > > > the ARM64 boot protocol, but in the case of ACPI, this contains pointers > > > to the ACPI tables, which are then used for populating the Linux platform > > > devices (unless acpi=disabled is set), while the other contents of the > > > DTB may be present but we skip the of_platform_populate state. > > > > > > If this is correct, then replacing the firmware-generated dtb with a > > > user-provided on would implicitly remove the ACPI tables from visibility, > > > which is exactly what we want. > > > > That's not quite true. > > > > There might not be any DTB, or the user might have provided a DTB with > > only /chosen/bootargs. Trying to distinguish the many cases of possible > > DTB is broken as a concept. > > > > The EFI stub will attempt to get a DTB from somewhere (provided by > > filename or as a system table with a magic UUID), and if it can't find > > one will generate an empty stub DTB. > > > > Then it will go and perform some EFI memory setup, placing some > > properties in the DTB (which might be a stub) describing the EFI memory > > map. > > > > Then we boot the kernel proper, which sees the EFI pointers and looks > > for an ACPI table. If they are found, ACPI is used. Otherwise we attempt > > to use the DTB (which might be a stub). > > > > Unless ACPI is explcitly disabled, ACPI will be used if present. > > Ah, I saw this after I replied to Arnd's email. > > The above sounds more like how I envisioned things working, so based on that, > the default just needs to be flipped and we should be fine (i.e. ACPI needs to > be explicitly enabled). Sorry, but I don't follow your reasoning. What is the rationale for disabling ACPI by default? That's not going to work for ACPI-only systems which may not have any HW described in a DTB. I fear it will result in more pain on any systems which try to ship both ACPI and DT, where ACPI will not get the testing it requires, leading to a greater possibility of quirks/workarounds being required later. Thanks, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.rutland@arm.com (Mark Rutland) Date: Mon, 28 Jul 2014 19:37:29 +0100 Subject: [PATCH 19/19] Documentation: ACPI for ARM64 In-Reply-To: <20140728163313.GC32359@quad.lixom.net> References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> <5014834.k6eecMddPC@wuerfel> <20140728101229.GD24078@leverpostej> <20140728163313.GC32359@quad.lixom.net> Message-ID: <20140728183729.GG2576@leverpostej> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jul 28, 2014 at 05:33:13PM +0100, Olof Johansson wrote: > On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote: > > On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote: > > > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote: > > > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo wrote: > > > > > +Relationship with Device Tree > > > > > +----------------------------- > > > > > + > > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually > > > > > +exclusive with DT support at compile time. > > > > > + > > > > > +At boot time the kernel will only use one description method depending on > > > > > +parameters passed from the bootloader. > > > > > > > > Possibly overriden by kernel bootargs. And as debated for quite a > > > > while earlier this year, acpi should still default to off -- if a DT > > > > and ACPI are both passed in, DT should at this time be given priority. > > > > > > I think this would be harder to do with the way that ACPI is passed in > > > to the kernel. IIRC, you always have a minimal DT information based on > > > the ARM64 boot protocol, but in the case of ACPI, this contains pointers > > > to the ACPI tables, which are then used for populating the Linux platform > > > devices (unless acpi=disabled is set), while the other contents of the > > > DTB may be present but we skip the of_platform_populate state. > > > > > > If this is correct, then replacing the firmware-generated dtb with a > > > user-provided on would implicitly remove the ACPI tables from visibility, > > > which is exactly what we want. > > > > That's not quite true. > > > > There might not be any DTB, or the user might have provided a DTB with > > only /chosen/bootargs. Trying to distinguish the many cases of possible > > DTB is broken as a concept. > > > > The EFI stub will attempt to get a DTB from somewhere (provided by > > filename or as a system table with a magic UUID), and if it can't find > > one will generate an empty stub DTB. > > > > Then it will go and perform some EFI memory setup, placing some > > properties in the DTB (which might be a stub) describing the EFI memory > > map. > > > > Then we boot the kernel proper, which sees the EFI pointers and looks > > for an ACPI table. If they are found, ACPI is used. Otherwise we attempt > > to use the DTB (which might be a stub). > > > > Unless ACPI is explcitly disabled, ACPI will be used if present. > > Ah, I saw this after I replied to Arnd's email. > > The above sounds more like how I envisioned things working, so based on that, > the default just needs to be flipped and we should be fine (i.e. ACPI needs to > be explicitly enabled). Sorry, but I don't follow your reasoning. What is the rationale for disabling ACPI by default? That's not going to work for ACPI-only systems which may not have any HW described in a DTB. I fear it will result in more pain on any systems which try to ship both ACPI and DT, where ACPI will not get the testing it requires, leading to a greater possibility of quirks/workarounds being required later. Thanks, Mark.