[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150107200530.GK2634@sirena.org.uk>
Date: Wed, 7 Jan 2015 20:05:30 +0000
From: Mark Brown <broonie@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Jon Masters <jcm@...hat.com>, linux-arm-kernel@...ts.infradead.org,
Catalin Marinas <catalin.marinas@....com>,
Rob Herring <robh@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Robert Richter <rric@...nel.org>,
Jason Cooper <jason@...edaemon.net>,
"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
Marc Zyngier <Marc.Zyngier@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Liviu Dudau <Liviu.Dudau@....com>,
Robert Moore <robert.moore@...el.com>,
Will Deacon <Will.Deacon@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Lv Zheng <lv.zheng@...el.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Olof Johansson <olof@...om.net>
Subject: Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64
On Wed, Jan 07, 2015 at 08:48:48PM +0100, Arnd Bergmann wrote:
> On Wednesday 07 January 2015 12:44:56 Jon Masters wrote:
> > On 01/07/2015 12:27 PM, Mark Brown wrote:
> > > That level of hardware compatibility does partly come from the need to
> > > run existing software. I'd expect that similar effects will start to
> > > come into play with ARMv8 ACPI systems if they become successful; people
> > > will do things like ensure compatibility with common IPs that have
> > > existing Linux drivers that distros tend to include as standard.
> > Agreed.
> There are two problems I see in trying to do the same thing on ARM:
> * we don't have a single vendor that makes de-facto standards that
> everyone else has to copy in the way that the few remaining x86
> vendors copy everything that Intel does. In fact, we prefer to
> have a large number of independent vendors.
Right, I'd guess that (modulo any standards being defined and becoming
successful) it'll more be a case of vendors keeping compatibility with
their own stuff. We *are* seeing greater reliance on off the shelf IPs
for more boring things like DMA and basic bus controllers but there's
plenty of other areas that still affect servers.
> * There is a general mindset about deprecating unwanted features
> early. ARMv8 aarch32 bit mode removes support for older instructions
> or makes them optional. Even the virtualization mode doesn't allow
> to trap on architecture version specific differences, so you can't
> completely emulate an older architecture level.
> This is nice for implementers but not so much for users that rely
> on old (mis-)features. It's also not just the CPU core, other
> components also get easily replaced, like a GICv3 that is not
> a strict superset of GICv2.
This is indeed worrying, though hopefully the fact that we're already
seeing negative impacts in the app ecosystem for Android will have
focused some minds - once you're talking about full system images it
gets even more fun.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists