From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: ACPI vs DT at runtime Date: Thu, 21 Nov 2013 19:33:02 +0100 Message-ID: <201311211933.03106.arnd@arndb.de> References: <20131121162944.F087FC406A3@trevor.secretlab.ca> <20131121175822.GA9590@quad.lixom.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131121175822.GA9590-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Olof Johansson Cc: Grant Likely , Mark Rutland , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Rob Herring List-Id: devicetree@vger.kernel.org On Thursday 21 November 2013, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and not expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. I think you are talking about different things here: Grant's example was about embedded x86 adding these so they can reuse the kernel infrastructure we already have without changing their entire firmware, which I think is fine, but he also said in the past that we wouldn't have that on PC-style ARM servers. Other people are pushing for that though (for SoC-style ARM servers I suppose), as Russell mentioned earlier. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Thu, 21 Nov 2013 19:33:02 +0100 Subject: ACPI vs DT at runtime In-Reply-To: <20131121175822.GA9590@quad.lixom.net> References: <20131121162944.F087FC406A3@trevor.secretlab.ca> <20131121175822.GA9590@quad.lixom.net> Message-ID: <201311211933.03106.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 21 November 2013, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and not expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. I think you are talking about different things here: Grant's example was about embedded x86 adding these so they can reuse the kernel infrastructure we already have without changing their entire firmware, which I think is fine, but he also said in the past that we wouldn't have that on PC-style ARM servers. Other people are pushing for that though (for SoC-style ARM servers I suppose), as Russell mentioned earlier. Arnd