ACPI vs DT at runtime

ACPI vs DT at runtime

[Olof Johansson]

The more I start to see early UEFI/ACPI code, the more I am certain
that we want none of that crap in the kernel. It's making things
considerably messier, while we're already very busy trying to convert
everything over and enable DT -- we'll be preempting that effort just
to add even more boilerplate everywhere and total progress will be
hurt.

The server guys really want UEFI for their boot protocols,
installation managers, etc, etc. That's fine, let them do that, but
that doesn't mean we need to bring the same APIs all the way into the
kernel.

So, I'm strongly urging that whatever the server guys try to do, it
will in the end result in the ACPI data being translated into DT
equivalents, such that the kernel _only_ needs to handle data via DT.

Just like PowerPC scrapes the OpenFirmware client interface to build a
flat device tree, we should add a pre-boot stage that scrapes
ACPI/UEFI data and constructs an appropriate device-tree. We can still
bring over ACPI methods and represent those in the DT, but we should
_not_ have two native interfaces.

It might be done via having a skeleton/framework DT for the vendor
platform that is updated via UEFI/ACPI data, or it might be
constructed entirely out of tables coming from firmware. I don't care
about the methods for how it is done, but I do feel strongly that we
should _not_ introduce a second API for everything. I can't think of a
single good reason to do it.


[There, commence centithread]

-Olof

ACPI vs DT at runtime

[Mark Rutland]

On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> The more I start to see early UEFI/ACPI code, the more I am certain
> that we want none of that crap in the kernel. It's making things
> considerably messier, while we're already very busy trying to convert
> everything over and enable DT -- we'll be preempting that effort just
> to add even more boilerplate everywhere and total progress will be
> hurt.

We are certainly under a lot of pressure with the device tree migration,
and I agree that adding another information source is going to be a
source of pain. However, I'd argue that we're going to encounter pain
regardless of which approach we take.

I'm of the opinion that the only way we should support ACPI is as a
first-class citizen. We don't need to modify every driver and subsystem
to support ACPI, only those necessary to support the minimal set of
platforms using ACPI. ACPI is new in the arm space, and we can enforce
quality standards on ACPI _now_ above what we're allowing for DT, and
avoid future problems.

There may even be things which we don't have to deal with at all on ACPI
systems as used in servers (e.g. clock management), but perhaps we will
if people see value in those elements.

> The server guys really want UEFI for their boot protocols,
> installation managers, etc, etc. That's fine, let them do that, but
> that doesn't mean we need to bring the same APIs all the way into the
> kernel.
> 
> So, I'm strongly urging that whatever the server guys try to do, it
> will in the end result in the ACPI data being translated into DT
> equivalents, such that the kernel _only_ needs to handle data via DT.

I'm not sure that translating ACPI tables to dt makes any sense. If AML
is used (even sparingly), I do not believe that we can do any sensible
conversion to device tree. My understanding is that AML includes
functionality for modifying ACPI tables, and I don't see how we can
possibly support that without having to add a lot of boilerplate to all
the code handling AML to add a device tree backend...

> Just like PowerPC scrapes the OpenFirmware client interface to build a
> flat device tree, we should add a pre-boot stage that scrapes
> ACPI/UEFI data and constructs an appropriate device-tree. We can still
> bring over ACPI methods and represent those in the DT, but we should
> _not_ have two native interfaces.

I'm not sure the two cases are comparable. The format of the FDT was
designed to encode the data structure used by OpenFirmware, and thus the
two map to each other pretty well. I do not believe that mapping from
ACPI tables to an FDT blob is anywhere near as simple, and as I mention
above I do not believe that we can just copy over the ACPI methods in
isolation.

> It might be done via having a skeleton/framework DT for the vendor
> platform that is updated via UEFI/ACPI data, or it might be
> constructed entirely out of tables coming from firmware. I don't care
> about the methods for how it is done, but I do feel strongly that we
> should _not_ introduce a second API for everything. I can't think of a
> single good reason to do it.

Where does this skeleton/framework come from? Within the kernel? That
sounds like an arcane board file equivalent, and is counter to the
entire reason for using UEFI and ACPI -- having a well-defined
(excluding particular driver bindings, and I'm not arguing well-defined
means nice) stable standard that allows the kernel to boot on an
arbitrary platform without requiring arbitrary platform-specific code
everywhere in the boot path.

It might not be pretty, and it will certainly require a lot of work, but
I'd prefer it at least for a semblance of uniformity.

I think that trying to shoe-horn ACPI-derived information into device
tree is fundamentally the wrong approach. I don't think it encourages
best practices, and I don't think it's beneficial to the long term
health of Linux or the ecosystem as a whole.

> [There, commence centithread]

[centithread commenced]

Thanks,
Mark.

ACPI vs DT at runtime

[Olof Johansson]

On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> > The more I start to see early UEFI/ACPI code, the more I am certain
> > that we want none of that crap in the kernel. It's making things
> > considerably messier, while we're already very busy trying to convert
> > everything over and enable DT -- we'll be preempting that effort just
> > to add even more boilerplate everywhere and total progress will be
> > hurt.
> 
> We are certainly under a lot of pressure with the device tree migration,
> and I agree that adding another information source is going to be a
> source of pain. However, I'd argue that we're going to encounter pain
> regardless of which approach we take.
> 
> I'm of the opinion that the only way we should support ACPI is as a
> first-class citizen. We don't need to modify every driver and subsystem
> to support ACPI, only those necessary to support the minimal set of
> platforms using ACPI. ACPI is new in the arm space, and we can enforce
> quality standards on ACPI _now_ above what we're allowing for DT, and
> avoid future problems.

It's obvious from the very first submission, from a vendor that has worked
closely with "the community" (i.e. one enterprise distro at least), that this
is completely new territory for _everyone_ involved. There's no way that we can
enforce quality standards for ACPI yet -- we don't know what they look like!
Nobody knows how to design a good ACPI implementation or binding.

Oh wait, there's people who have been doing this for years. Microsoft. They
should be the ones driving this and taking the pain for it. Once the platform
is enabled for their needs, we'll sort it out at our end. After all, that has
worked reasonably well for x86 platforms.

If we knew exactly what we wanted, it'd be a different story. _We
don't_. We're into year FOUR of the device tree conversion and we're just
now reaching a point where we think we know what a good solution looks
like. The first two years were easy -- they were the trivial devices we're
now talking about on ACPI. After that it got harder. Going through all
of that again with ACPI? No. No way. Microsoft gets to do it and while
they're busy sorting it out, we'll boot with device tree.

Once they're done, we'll figure out how to enable new hardware. Sure, someone
needs to keep them sane and participate in the standardization process, but we
don't have to drag the whole kernel through it.

> There may even be things which we don't have to deal with at all on ACPI
> systems as used in servers (e.g. clock management), but perhaps we will
> if people see value in those elements.

It's not about seeing value, it's about trying to shoehorn an existing
implementation into ACPI right now. People don't program with the ACPI
mindset since that's not what they're used to. So everybody needs to
re-learn everything all over again.

The clock issues still have to be dealt with in ACPI _somewhere_,
and they likely have to be dealt with by the same software team at the
vendors that do Linux kernel work. So by forcing them to figure out how
to do it in ACPI, we're distracting from their efforts to support their
hardware better in the kernel in the first place. That's not win-win,
it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft
since they are DoS:ing us.

> > The server guys really want UEFI for their boot protocols,
> > installation managers, etc, etc. That's fine, let them do that, but
> > that doesn't mean we need to bring the same APIs all the way into the
> > kernel.
> > 
> > So, I'm strongly urging that whatever the server guys try to do, it
> > will in the end result in the ACPI data being translated into DT
> > equivalents, such that the kernel _only_ needs to handle data via DT.
> 
> I'm not sure that translating ACPI tables to dt makes any sense. If AML
> is used (even sparingly), I do not believe that we can do any sensible
> conversion to device tree. My understanding is that AML includes
> functionality for modifying ACPI tables, and I don't see how we can
> possibly support that without having to add a lot of boilerplate to all
> the code handling AML to add a device tree backend...

We can definitely modify device tree contents at runtime, it's just that
nobody besides the POWER server guys are doing that today. So that's
not a strong argument in ACPI's favor. We should fix device-tree where
needed instead.

Also, we can either have some of our better people sort out the ACPI-to-DT
translation and management, and get it done right, or we can rely on all the
vendors to get ACPI right in all their drivers. While some of them will,
I suspect we'll be more successful driving this from a common place. It
also gives us a place to stick all the fixups for broken firmware,
since the first generations of ARM servers are bound to have them.

And best of all, it allows us to continue focus on device tree and
getting that done right, than splitting all efforts into two. We can't
affort that right now.

> > Just like PowerPC scrapes the OpenFirmware client interface to build a
> > flat device tree, we should add a pre-boot stage that scrapes
> > ACPI/UEFI data and constructs an appropriate device-tree. We can still
> > bring over ACPI methods and represent those in the DT, but we should
> > _not_ have two native interfaces.
> 
> I'm not sure the two cases are comparable. The format of the FDT was
> designed to encode the data structure used by OpenFirmware, and thus the
> two map to each other pretty well. I do not believe that mapping from
> ACPI tables to an FDT blob is anywhere near as simple, and as I mention
> above I do not believe that we can just copy over the ACPI methods in
> isolation.

Sorry, I wasn't implying that there's a one-time trivial conversion
to be made in the generic case, but it can still be done in a similar
manner even though it will be more complex.

Nobody is expecting there to be zero work for new drivers with ACPI;
after all, the driver itself still has to be written. We're talking differences
from board to board and system to system here, which we can definitely handle
through a translator as well.

And, as you say, if the first platforms are going to be trivial and easy to
implement with ACPI, then doing a translation for them will be simple too.

Shipping a firmware with ACPI is really no different from shipping a firmware
with a flashed device tree. Whatever bugs or strange things the vendor chooses
to do in there, we'll have to live with forever.

We all know DT considerably better to a point where I would recommend
that they flash a DTB in their UEFI firmware instead of go with ACPI. For
simple hardware and basic devices we've got most bindings sorted out by
now, and we've decided on backwards compatibility from here on out.

> > It might be done via having a skeleton/framework DT for the vendor
> > platform that is updated via UEFI/ACPI data, or it might be
> > constructed entirely out of tables coming from firmware. I don't care
> > about the methods for how it is done, but I do feel strongly that we
> > should _not_ introduce a second API for everything. I can't think of a
> > single good reason to do it.
> 
> Where does this skeleton/framework come from? Within the kernel?

Since there might need to be runtime modifications done to the tree based on
ACPI events, it seems to make sense to do it in the kernel, so that translation
state and such can be kept around for use by the runtime modification parts.

Having it extractable out of the kernel tree for testing purposes would be
greatly appreciated, so it can be ran through valgrind, add testcases, etc.

> That
> sounds like an arcane board file equivalent, and is counter to the
> entire reason for using UEFI and ACPI -- having a well-defined
> (excluding particular driver bindings, and I'm not arguing well-defined
> means nice) stable standard that allows the kernel to boot on an
> arbitrary platform without requiring arbitrary platform-specific code
> everywhere in the boot path.
> 
> It might not be pretty, and it will certainly require a lot of work, but
> I'd prefer it at least for a semblance of uniformity.

That is a red herring -- that booting standard has _nothing_ to do with
ACPI. Once you've got a standard that is well-defined enough like that,
you no longer need the runtime portions of ACPI to deal with it. You
can just hardcode it. You need a way to probe _which_ type of standard
is used, but from there on out you can assume that things are the same
way.

> I think that trying to shoe-horn ACPI-derived information into device
> tree is fundamentally the wrong approach. I don't think it encourages
> best practices, and I don't think it's beneficial to the long term
> health of Linux or the ecosystem as a whole.

There are no known best practices with ACPI. It's a complete fumbling
around in the dark right now. We're complaining about reviewer bandwith
on DT -- do we have a single reviewer for ACPI on ARM that actually
knows what a good solution looks like? I don't think so.

So, until there's strong evidence that ACPI is actually going to be
a sane solution, in other words, until someone has shipped a system
that uses it (with Windows) and does it successfully without being
a hot mess, we shouldn't litter the kernel with it.

Vendors can standardise of UEFI if they want, but I would much rather
see them bundle DTB images with their firmware today, than rely on early
buggy and still-early-on-the-learning-curve ACPI bindings that we then
have to live with forever.


-Olof

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> If we knew exactly what we wanted, it'd be a different story. _We
> don't_. We're into year FOUR of the device tree conversion and we're just
> now reaching a point where we think we know what a good solution looks
> like. The first two years were easy -- they were the trivial devices we're
> now talking about on ACPI. After that it got harder. Going through all
> of that again with ACPI? No. No way. Microsoft gets to do it and while
> they're busy sorting it out, we'll boot with device tree.

However, there's a very big danger here.  I disagree with the stance
you're taking.

It seems that under ACPI and DT, we refer to properties by string names.
That's good, but do we really want to have different string names for the
same property.

Or worse still, the same hardware property described in two completely
different ways between ACPI and DT?

If you think Microsoft will come along, look at what we've done for DT,
and implement something in ACPI which is somehow compatible with that,
I'd have to ask where you've been for the last 30 years.  That's not
how Microsoft operates.

Microsoft will instead design something different (whether it's
intentionally different or not depends on your point of view) but it
will be designed how they want and not how we'd like it to be.  From
their point of view, if it's completely different and very difficult
to convert to device tree, that's a win for them because it means
they're pushing back on Linux being used in markets they wish to be
successful.

We have a possibility here to define how we'd like ACPI to look: we
have the chance to have ACPI properties using the same naming that we
already have for DT.  What this means is that _if_ we wanted one day
to have first class support for ACPI (which we may wish to for the
AML) then we wouldn't have to rewrite all the drivers we've already
converted.  Yes, we'd have a some churn, but most of that would be
along the lines of converting the of_* calls to being firmware_*
calls, taking a generic firmware handle.

Who knows, we may decide in the future that we want to move everything
over to ACPI rather than using DT, and having things as I mention above
would make it much easier to convert from DT to ACPI.

I believe that we're only going to regret shutting the door on this
in the future.  It's not like the kernel doesn't already have native
support for ACPI.

ACPI vs DT at runtime

[Olof Johansson]

On Fri, Nov 15, 2013 at 10:08 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
>> If we knew exactly what we wanted, it'd be a different story. _We
>> don't_. We're into year FOUR of the device tree conversion and we're just
>> now reaching a point where we think we know what a good solution looks
>> like. The first two years were easy -- they were the trivial devices we're
>> now talking about on ACPI. After that it got harder. Going through all
>> of that again with ACPI? No. No way. Microsoft gets to do it and while
>> they're busy sorting it out, we'll boot with device tree.
>
> However, there's a very big danger here.  I disagree with the stance
> you're taking.
>
> It seems that under ACPI and DT, we refer to properties by string names.
> That's good, but do we really want to have different string names for the
> same property.
>
> Or worse still, the same hardware property described in two completely
> different ways between ACPI and DT?
>
> If you think Microsoft will come along, look at what we've done for DT,
> and implement something in ACPI which is somehow compatible with that,
> I'd have to ask where you've been for the last 30 years.  That's not
> how Microsoft operates.
>
> Microsoft will instead design something different (whether it's
> intentionally different or not depends on your point of view) but it
> will be designed how they want and not how we'd like it to be.  From
> their point of view, if it's completely different and very difficult
> to convert to device tree, that's a win for them because it means
> they're pushing back on Linux being used in markets they wish to be
> successful.

Main reply at the bottom but on this: I don't know if this is already
happening. Given that APM is asking us how to do clock bindings, I'm
guessing they're not working with Microsoft on ACPI yet. So I have no
idea if there's a complete impedance mismatch between what we're tying
to do, and what they will later require, or not. They might chose to
discard any ACPI implementation that's been written just to Linux, and
have their own set of criteria. We just don't know at this time since
I get the impression we're working on our own right now.

> We have a possibility here to define how we'd like ACPI to look: we
> have the chance to have ACPI properties using the same naming that we
> already have for DT.  What this means is that _if_ we wanted one day
> to have first class support for ACPI (which we may wish to for the
> AML) then we wouldn't have to rewrite all the drivers we've already
> converted.  Yes, we'd have a some churn, but most of that would be
> along the lines of converting the of_* calls to being firmware_*
> calls, taking a generic firmware handle.
>
> Who knows, we may decide in the future that we want to move everything
> over to ACPI rather than using DT, and having things as I mention above
> would make it much easier to convert from DT to ACPI.
>
> I believe that we're only going to regret shutting the door on this
> in the future.  It's not like the kernel doesn't already have native
> support for ACPI.

Yeah, I should have been clearer on that: It still makes much sense to
make sure that we have Linux representation in the UEFI/ACPI standards
committees, and it's my impression that Linaro is providing that --
that's a good initiative and should continue. It is particularly true
once we move off the path of the simple initial stuff and start to
enter corner cases of where things don't fit the standard model (like
we're at with DT now), since we'd need to come up with common
solutions.


-Olof

ACPI vs DT at runtime

[Arnd Bergmann]

On Friday 15 November 2013, Russell King - ARM Linux wrote:
> On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> > If we knew exactly what we wanted, it'd be a different story. _We
> > don't_. We're into year FOUR of the device tree conversion and we're just
> > now reaching a point where we think we know what a good solution looks
> > like. The first two years were easy -- they were the trivial devices we're
> > now talking about on ACPI. After that it got harder. Going through all
> > of that again with ACPI? No. No way. Microsoft gets to do it and while
> > they're busy sorting it out, we'll boot with device tree.
> 
> However, there's a very big danger here.  I disagree with the stance
> you're taking.
> 
> It seems that under ACPI and DT, we refer to properties by string names.
> That's good, but do we really want to have different string names for the
> same property.

For all I know, doing this in ACPI is something that is only now being
discussed as Intel wants to be able to reuse the existing features from
DT enabled drivers in the kernel and share the implementation between
embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually
isn't as crazy.

The existing ACPI usage however is basically all binary and cannot be
shared with DT, in particular it won't help for the orthogonal problem of
using ACPI to get "enterprise server" features on ARM64.

> Or worse still, the same hardware property described in two completely
> different ways between ACPI and DT?

I think we should definitely try to have the same peripherals on ACPI
and DT use the same bindings for device-specific properties (once we
have a agreed on how those are done in ACPI), but I think that's the
easier part of the problem.

For anything that defines a connection between two a consumer and a
producer (IRQ, DMA, pinmux, GPIO, regulator, ...), we need subsystem
specific code for each firmware interface, simply because the way to
refer to another node is so wildly different.

	Arnd

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> On Friday 15 November 2013, Russell King - ARM Linux wrote:
> > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> > > If we knew exactly what we wanted, it'd be a different story. _We
> > > don't_. We're into year FOUR of the device tree conversion and we're just
> > > now reaching a point where we think we know what a good solution looks
> > > like. The first two years were easy -- they were the trivial devices we're
> > > now talking about on ACPI. After that it got harder. Going through all
> > > of that again with ACPI? No. No way. Microsoft gets to do it and while
> > > they're busy sorting it out, we'll boot with device tree.
> > 
> > However, there's a very big danger here.  I disagree with the stance
> > you're taking.
> > 
> > It seems that under ACPI and DT, we refer to properties by string names.
> > That's good, but do we really want to have different string names for the
> > same property.
> 
> For all I know, doing this in ACPI is something that is only now being
> discussed as Intel wants to be able to reuse the existing features from
> DT enabled drivers in the kernel and share the implementation between
> embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually
> isn't as crazy.
> 
> The existing ACPI usage however is basically all binary and cannot be
> shared with DT, in particular it won't help for the orthogonal problem of
> using ACPI to get "enterprise server" features on ARM64.

That's strange, because the patches I've seen from people who want to
add ACPI support to AMBA are all based around very similar strings to
those in DT to lookup the same data in ACPI.

What's been done there is the function which reads from DT has been
duplicated, and instead of reading the information from DT, it reads it
from ACPI instead using string names without the vendor prefix.

That tells me that what I've stated in my previous email to which you
replied is _definitely_ possible to do.  That means it's certainly
possible to do this without reinventing the wheel, and without having
to rewrite lots of parsing code, precisely along the lines I set out
in my original email.

ACPI vs DT at runtime

[Arnd Bergmann]

On Saturday 16 November 2013, Russell King - ARM Linux wrote:
> On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> > 
> > For all I know, doing this in ACPI is something that is only now being
> > discussed as Intel wants to be able to reuse the existing features from
> > DT enabled drivers in the kernel and share the implementation between
> > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually
> > isn't as crazy.
> > 
> > The existing ACPI usage however is basically all binary and cannot be
> > shared with DT, in particular it won't help for the orthogonal problem of
> > using ACPI to get "enterprise server" features on ARM64.
> 
> That's strange, because the patches I've seen from people who want to
> add ACPI support to AMBA are all based around very similar strings to
> those in DT to lookup the same data in ACPI.

Can you point to specific patches? I can't say I'm an expert on this, but
everything I've seen with ACPI is tables of binary data with four-letter
identifiers that are defined by the ACPI group, but not using strings
in a similar manner to DT. Apple has an extension to do DT-style properties
in their phones, and we had a discussion at the kernel summit to do
a more generic variation of the same idea that Darren Hart presented,
but that is still in prototype stage.

> What's been done there is the function which reads from DT has been
> duplicated, and instead of reading the information from DT, it reads it
> from ACPI instead using string names without the vendor prefix.

The recently posted x-gene ahci driver does this, but from what I can
tell, the implementation is inappropriate on both DT (because of the
use of unreadable four-character upper-case identifiers) and on ACPI
(because of the use of non-standard identifiers).

> That tells me that what I've stated in my previous email to which you
> replied is _definitely_ possible to do.  That means it's certainly
> possible to do this without reinventing the wheel, and without having
> to rewrite lots of parsing code, precisely along the lines I set out
> in my original email.

To clarify my complaint: while we can do simple (boolean, integer, text,
or arrays of those three) properties with Darren's approach as long as they
are private to one device, that won't suffice for anything that requires
links between devices. We have phandles on DT that can be freely mixed with
integers for things like GPIO or clock references. ACPI has similar
references, but uses a different syntax for doing the same things, and these
have to be standardized per subsystem (i.e. per type of connection) to make
sense.
As a result, every subsystem that has a producer-consumer type connection
requires different code for DT and for ACPI. If the subsystem-to-driver
interface is done well, we can have a common device driver, but in a 
lot of cases there will be a leaky abstraction. As Olof pointed out,
even migrating from a DT-only interface to a generic interface would
require changing each driver, even if the result is no more ugly than
the current state.

	Arnd

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Mon, Nov 18, 2013 at 04:05:37PM +0100, Arnd Bergmann wrote:
> On Saturday 16 November 2013, Russell King - ARM Linux wrote:
> > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> > > 
> > > For all I know, doing this in ACPI is something that is only now being
> > > discussed as Intel wants to be able to reuse the existing features from
> > > DT enabled drivers in the kernel and share the implementation between
> > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually
> > > isn't as crazy.
> > > 
> > > The existing ACPI usage however is basically all binary and cannot be
> > > shared with DT, in particular it won't help for the orthogonal problem of
> > > using ACPI to get "enterprise server" features on ARM64.
> > 
> > That's strange, because the patches I've seen from people who want to
> > add ACPI support to AMBA are all based around very similar strings to
> > those in DT to lookup the same data in ACPI.
> 
> Can you point to specific patches?

No, because they weren't publically posted, so I don't feel that I can
say all that much; they were from quite a large company though.

> I can't say I'm an expert on this, but everything I've seen with ACPI
> is tables of binary data with four-letter identifiers that are defined
> by the ACPI group, but not using strings in a similar manner to DT.

They are using strings which are the same as the DT properties, but
without the vendor prefix - but yes, to only retrieve things like
booleans, u32s and such like.  They also have support for fixed-rate
clocks via the clk API too...

I'd like them to post the patches publically so a more open discussion
could occur.

ACPI vs DT at runtime

[Arnd Bergmann]

On Monday 18 November 2013, Russell King - ARM Linux wrote:
> > Can you point to specific patches?
> 
> No, because they weren't publically posted, so I don't feel that I can
> say all that much; they were from quite a large company though.

I see.

> > I can't say I'm an expert on this, but everything I've seen with ACPI
> > is tables of binary data with four-letter identifiers that are defined
> > by the ACPI group, but not using strings in a similar manner to DT.
> 
> They are using strings which are the same as the DT properties, but
> without the vendor prefix - but yes, to only retrieve things like
> booleans, u32s and such like.  They also have support for fixed-rate
> clocks via the clk API too...
> 
> I'd like them to post the patches publically so a more open discussion
> could occur.

I'd definitely like that too, especially since managing clocks etc.
is (as multiple people have pointed out in this thread) a very
un-ACPI-like thing to do and it would be important for them to have
the debate whether that has a chance of getting accepted in the kernel
(or the ACPI spec, for that matter) or not.

	Arnd

ACPI vs DT at runtime

[Grant Likely]

On Mon, 18 Nov 2013 15:19:01 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> They are using strings which are the same as the DT properties, but
> without the vendor prefix - but yes, to only retrieve things like
> booleans, u32s and such like.  They also have support for fixed-rate
> clocks via the clk API too...
> 
> I'd like them to post the patches publically so a more open discussion
> could occur.

Indeed.

g.

ACPI vs DT at runtime

[Grant Likely]

On Mon, 18 Nov 2013 16:05:37 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 16 November 2013, Russell King - ARM Linux wrote:
> > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> > > 
> > > For all I know, doing this in ACPI is something that is only now being
> > > discussed as Intel wants to be able to reuse the existing features from
> > > DT enabled drivers in the kernel and share the implementation between
> > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually
> > > isn't as crazy.
> > > 
> > > The existing ACPI usage however is basically all binary and cannot be
> > > shared with DT, in particular it won't help for the orthogonal problem of
> > > using ACPI to get "enterprise server" features on ARM64.
> > 
> > That's strange, because the patches I've seen from people who want to
> > add ACPI support to AMBA are all based around very similar strings to
> > those in DT to lookup the same data in ACPI.
> 
> Can you point to specific patches? I can't say I'm an expert on this, but
> everything I've seen with ACPI is tables of binary data with four-letter
> identifiers that are defined by the ACPI group, but not using strings
> in a similar manner to DT. Apple has an extension to do DT-style properties
> in their phones, and we had a discussion at the kernel summit to do
> a more generic variation of the same idea that Darren Hart presented,
> but that is still in prototype stage.

ACPI is a mix of binary tables (can be dereferenced directly as C
structs) and the "ACPI Namespace" which looks remarkably like a device
tree, except the nodes contains bytecode methods instead of static
properties. Many of the methods are defined by the ACPI standard to be
called for various events; like initialization and power management
activities. A lot of core devices on the platform are described both in
the static tables and the ACPI namespace.

(The ACPI namepaces is the structure decoded by interpreting the bytecode
in the DSDT and SSDT tables.)

As I see it, ACPI prefers to defer the difficult bits to the platform
by using a bytecode to perform arbitrary operations. DT on the other
hand defers to the kernel.

> > What's been done there is the function which reads from DT has been
> > duplicated, and instead of reading the information from DT, it reads it
> > from ACPI instead using string names without the vendor prefix.
> 
> The recently posted x-gene ahci driver does this, but from what I can
> tell, the implementation is inappropriate on both DT (because of the
> use of unreadable four-character upper-case identifiers) and on ACPI
> (because of the use of non-standard identifiers).
> 
> > That tells me that what I've stated in my previous email to which you
> > replied is _definitely_ possible to do.  That means it's certainly
> > possible to do this without reinventing the wheel, and without having
> > to rewrite lots of parsing code, precisely along the lines I set out
> > in my original email.
> 
> To clarify my complaint: while we can do simple (boolean, integer, text,
> or arrays of those three) properties with Darren's approach as long as they
> are private to one device, that won't suffice for anything that requires
> links between devices. We have phandles on DT that can be freely mixed with
> integers for things like GPIO or clock references. ACPI has similar
> references, but uses a different syntax for doing the same things, and these
> have to be standardized per subsystem (i.e. per type of connection) to make
> sense.
> As a result, every subsystem that has a producer-consumer type connection
> requires different code for DT and for ACPI. If the subsystem-to-driver
> interface is done well, we can have a common device driver, but in a 
> lot of cases there will be a leaky abstraction. As Olof pointed out,
> even migrating from a DT-only interface to a generic interface would
> require changing each driver, even if the result is no more ugly than
> the current state.

This too should look transparent to device drivers. DT and ACPI have
different mechanism for doing cross tree references, but the concept is
the same. A driver calling something like "platform_get_my_gpio_resource()"
should do the right thing with either an ACPI or DT backend. None of
that should appear as custom device driver or architecture code. It
should be generic code supporting the driver core.

Regardless of the ACPI on ARM question, we need to do this anyway. There
are Intel platforms that need it.

g.

ACPI vs DT at runtime

[Arnd Bergmann]

On Thursday 21 November 2013, Grant Likely wrote:
> This too should look transparent to device drivers. DT and ACPI have
> different mechanism for doing cross tree references, but the concept is
> the same. A driver calling something like "platform_get_my_gpio_resource()"
> should do the right thing with either an ACPI or DT backend. None of
> that should appear as custom device driver or architecture code. It
> should be generic code supporting the driver core.

I definitely agree with the approach, and I've already made some suggestions
for how to implement parts of this. The problem is that this will touch
dozens of subsystems and hundreds of device drivers. We have the experience
of having done it all before when introducing the DT interfaces and some of
the new subsystems, which is a big advantage for doing it again, but on the
other hand there are now more drivers than we had before, and we have to
be more careful so we don't break the existing code base.

> Regardless of the ACPI on ARM question, we need to do this anyway. There
> are Intel platforms that need it.

There is certainly some overhead, but my guess is that it's actually
less than half of the total work because they are trying to do something
completely different:

- Intel are doing this only for embedded systems, so they don't have to
  worry about subsystems that are only relevant to servers (e.g. fault
  isolation)
- Significant parts of the x86 architecture are completely standardized
  and don't need to be described in a complex matter (e.g. IOMMU)
+ A number of subsystems that Intel needs to handle on embedded systems
  should really not be described in detail on servers on any architecture
  but instead be handled in AML or SMBIOS (e.g. pinctrl or phy).
+ Some subsystems won't even be used on servers and don't need to be
  handled at all but are very relevant to embedded systems (e.g. v4l or
  dmaengine)

For the parts that do overlap (e.g. irqdomain or reset), we should
certainly work together across architectures. 

	Arnd

ACPI vs DT at runtime

[Mark Brown]

On Thu, Nov 21, 2013 at 07:26:02PM +0100, Arnd Bergmann wrote:

> + A number of subsystems that Intel needs to handle on embedded systems
>   should really not be described in detail on servers on any architecture
>   but instead be handled in AML or SMBIOS (e.g. pinctrl or phy).

Are we 100% sure about this assumption?  We're saying "server" here but
how much of that is really "distro" - if it is distro then you start to
get things like laptops coming into play which do have a lot more of the
fun stuff that we see on embedded devices in active use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131121/2b2de12c/attachment.sig>

ACPI vs DT at runtime

[Grant Likely]

On Fri, 15 Nov 2013 23:21:09 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> > On Friday 15 November 2013, Russell King - ARM Linux wrote:
> > > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> > > > If we knew exactly what we wanted, it'd be a different story. _We
> > > > don't_. We're into year FOUR of the device tree conversion and we're just
> > > > now reaching a point where we think we know what a good solution looks
> > > > like. The first two years were easy -- they were the trivial devices we're
> > > > now talking about on ACPI. After that it got harder. Going through all
> > > > of that again with ACPI? No. No way. Microsoft gets to do it and while
> > > > they're busy sorting it out, we'll boot with device tree.
> > > 
> > > However, there's a very big danger here.  I disagree with the stance
> > > you're taking.
> > > 
> > > It seems that under ACPI and DT, we refer to properties by string names.
> > > That's good, but do we really want to have different string names for the
> > > same property.
> > 
> > For all I know, doing this in ACPI is something that is only now being
> > discussed as Intel wants to be able to reuse the existing features from
> > DT enabled drivers in the kernel and share the implementation between
> > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually
> > isn't as crazy.
> > 
> > The existing ACPI usage however is basically all binary and cannot be
> > shared with DT, in particular it won't help for the orthogonal problem of
> > using ACPI to get "enterprise server" features on ARM64.
> 
> That's strange, because the patches I've seen from people who want to
> add ACPI support to AMBA are all based around very similar strings to
> those in DT to lookup the same data in ACPI.
> 
> What's been done there is the function which reads from DT has been
> duplicated, and instead of reading the information from DT, it reads it
> from ACPI instead using string names without the vendor prefix.

The fact that they are using different strings is a problem though. Push
back on that. As much as possible the property formats between DT and
ACPI should be identical. This is entirely new territory for ACPI and we
have significant influence over it.

g.

ACPI vs DT at runtime

[David Goodenough]

On Friday 15 Nov 2013, Olof Johansson wrote:
> On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> > > The more I start to see early UEFI/ACPI code, the more I am certain
> > > that we want none of that crap in the kernel. It's making things
> > > considerably messier, while we're already very busy trying to convert
> > > everything over and enable DT -- we'll be preempting that effort just
> > > to add even more boilerplate everywhere and total progress will be
> > > hurt.
> > 
> > We are certainly under a lot of pressure with the device tree migration,
> > and I agree that adding another information source is going to be a
> > source of pain. However, I'd argue that we're going to encounter pain
> > regardless of which approach we take.
> > 
> > I'm of the opinion that the only way we should support ACPI is as a
> > first-class citizen. We don't need to modify every driver and subsystem
> > to support ACPI, only those necessary to support the minimal set of
> > platforms using ACPI. ACPI is new in the arm space, and we can enforce
> > quality standards on ACPI _now_ above what we're allowing for DT, and
> > avoid future problems.
> 
> It's obvious from the very first submission, from a vendor that has worked
> closely with "the community" (i.e. one enterprise distro at least), that
> this is completely new territory for _everyone_ involved. There's no way
> that we can enforce quality standards for ACPI yet -- we don't know what
> they look like! Nobody knows how to design a good ACPI implementation or
> binding.
> 
> Oh wait, there's people who have been doing this for years. Microsoft. They
> should be the ones driving this and taking the pain for it. Once the
> platform is enabled for their needs, we'll sort it out at our end. After
> all, that has worked reasonably well for x86 platforms.
> 
> If we knew exactly what we wanted, it'd be a different story. _We
> don't_. We're into year FOUR of the device tree conversion and we're just
> now reaching a point where we think we know what a good solution looks
> like. The first two years were easy -- they were the trivial devices we're
> now talking about on ACPI. After that it got harder. Going through all
> of that again with ACPI? No. No way. Microsoft gets to do it and while
> they're busy sorting it out, we'll boot with device tree.
> 
> Once they're done, we'll figure out how to enable new hardware. Sure,
> someone needs to keep them sane and participate in the standardization
> process, but we don't have to drag the whole kernel through it.
> 
> > There may even be things which we don't have to deal with at all on ACPI
> > systems as used in servers (e.g. clock management), but perhaps we will
> > if people see value in those elements.
> 
> It's not about seeing value, it's about trying to shoehorn an existing
> implementation into ACPI right now. People don't program with the ACPI
> mindset since that's not what they're used to. So everybody needs to
> re-learn everything all over again.
> 
> The clock issues still have to be dealt with in ACPI _somewhere_,
> and they likely have to be dealt with by the same software team at the
> vendors that do Linux kernel work. So by forcing them to figure out how
> to do it in ACPI, we're distracting from their efforts to support their
> hardware better in the kernel in the first place. That's not win-win,
> it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft
> since they are DoS:ing us.
> 
> > > The server guys really want UEFI for their boot protocols,
> > > installation managers, etc, etc. That's fine, let them do that, but
> > > that doesn't mean we need to bring the same APIs all the way into the
> > > kernel.
> > > 
> > > So, I'm strongly urging that whatever the server guys try to do, it
> > > will in the end result in the ACPI data being translated into DT
> > > equivalents, such that the kernel _only_ needs to handle data via DT.
> > 
> > I'm not sure that translating ACPI tables to dt makes any sense. If AML
> > is used (even sparingly), I do not believe that we can do any sensible
> > conversion to device tree. My understanding is that AML includes
> > functionality for modifying ACPI tables, and I don't see how we can
> > possibly support that without having to add a lot of boilerplate to all
> > the code handling AML to add a device tree backend...
> 
> We can definitely modify device tree contents at runtime, it's just that
> nobody besides the POWER server guys are doing that today. So that's
> not a strong argument in ACPI's favor. We should fix device-tree where
> needed instead.
Is this true.  On the Beagle Board/Bone there is extensive use of Device
Tree Overlays, which feels like run time modification to me.  It gets 
used to enable multiplexed pins to a particular configuration.

David
> 
> Also, we can either have some of our better people sort out the ACPI-to-DT
> translation and management, and get it done right, or we can rely on all
> the vendors to get ACPI right in all their drivers. While some of them
> will, I suspect we'll be more successful driving this from a common place.
> It also gives us a place to stick all the fixups for broken firmware,
> since the first generations of ARM servers are bound to have them.
> 
> And best of all, it allows us to continue focus on device tree and
> getting that done right, than splitting all efforts into two. We can't
> affort that right now.
> 
> > > Just like PowerPC scrapes the OpenFirmware client interface to build a
> > > flat device tree, we should add a pre-boot stage that scrapes
> > > ACPI/UEFI data and constructs an appropriate device-tree. We can still
> > > bring over ACPI methods and represent those in the DT, but we should
> > > _not_ have two native interfaces.
> > 
> > I'm not sure the two cases are comparable. The format of the FDT was
> > designed to encode the data structure used by OpenFirmware, and thus the
> > two map to each other pretty well. I do not believe that mapping from
> > ACPI tables to an FDT blob is anywhere near as simple, and as I mention
> > above I do not believe that we can just copy over the ACPI methods in
> > isolation.
> 
> Sorry, I wasn't implying that there's a one-time trivial conversion
> to be made in the generic case, but it can still be done in a similar
> manner even though it will be more complex.
> 
> Nobody is expecting there to be zero work for new drivers with ACPI;
> after all, the driver itself still has to be written. We're talking
> differences from board to board and system to system here, which we can
> definitely handle through a translator as well.
> 
> And, as you say, if the first platforms are going to be trivial and easy to
> implement with ACPI, then doing a translation for them will be simple too.
> 
> Shipping a firmware with ACPI is really no different from shipping a
> firmware with a flashed device tree. Whatever bugs or strange things the
> vendor chooses to do in there, we'll have to live with forever.
> 
> We all know DT considerably better to a point where I would recommend
> that they flash a DTB in their UEFI firmware instead of go with ACPI. For
> simple hardware and basic devices we've got most bindings sorted out by
> now, and we've decided on backwards compatibility from here on out.
> 
> > > It might be done via having a skeleton/framework DT for the vendor
> > > platform that is updated via UEFI/ACPI data, or it might be
> > > constructed entirely out of tables coming from firmware. I don't care
> > > about the methods for how it is done, but I do feel strongly that we
> > > should _not_ introduce a second API for everything. I can't think of a
> > > single good reason to do it.
> > 
> > Where does this skeleton/framework come from? Within the kernel?
> 
> Since there might need to be runtime modifications done to the tree based
> on ACPI events, it seems to make sense to do it in the kernel, so that
> translation state and such can be kept around for use by the runtime
> modification parts.
> 
> Having it extractable out of the kernel tree for testing purposes would be
> greatly appreciated, so it can be ran through valgrind, add testcases, etc.
> 
> > That
> > sounds like an arcane board file equivalent, and is counter to the
> > entire reason for using UEFI and ACPI -- having a well-defined
> > (excluding particular driver bindings, and I'm not arguing well-defined
> > means nice) stable standard that allows the kernel to boot on an
> > arbitrary platform without requiring arbitrary platform-specific code
> > everywhere in the boot path.
> > 
> > It might not be pretty, and it will certainly require a lot of work, but
> > I'd prefer it at least for a semblance of uniformity.
> 
> That is a red herring -- that booting standard has _nothing_ to do with
> ACPI. Once you've got a standard that is well-defined enough like that,
> you no longer need the runtime portions of ACPI to deal with it. You
> can just hardcode it. You need a way to probe _which_ type of standard
> is used, but from there on out you can assume that things are the same
> way.
> 
> > I think that trying to shoe-horn ACPI-derived information into device
> > tree is fundamentally the wrong approach. I don't think it encourages
> > best practices, and I don't think it's beneficial to the long term
> > health of Linux or the ecosystem as a whole.
> 
> There are no known best practices with ACPI. It's a complete fumbling
> around in the dark right now. We're complaining about reviewer bandwith
> on DT -- do we have a single reviewer for ACPI on ARM that actually
> knows what a good solution looks like? I don't think so.
> 
> So, until there's strong evidence that ACPI is actually going to be
> a sane solution, in other words, until someone has shipped a system
> that uses it (with Windows) and does it successfully without being
> a hot mess, we shouldn't litter the kernel with it.
> 
> Vendors can standardise of UEFI if they want, but I would much rather
> see them bundle DTB images with their firmware today, than rely on early
> buggy and still-early-on-the-learning-curve ACPI bindings that we then
> have to live with forever.
> 
> 
> -Olof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

ACPI vs DT at runtime

[Grant Likely]

On Fri, 15 Nov 2013 18:13:47 +0000, David Goodenough <david.goodenough@btconnect.com> wrote:
> On Friday 15 Nov 2013, Olof Johansson wrote:
> > > I'm not sure that translating ACPI tables to dt makes any sense. If AML
> > > is used (even sparingly), I do not believe that we can do any sensible
> > > conversion to device tree. My understanding is that AML includes
> > > functionality for modifying ACPI tables, and I don't see how we can
> > > possibly support that without having to add a lot of boilerplate to all
> > > the code handling AML to add a device tree backend...
> > 
> > We can definitely modify device tree contents at runtime, it's just that
> > nobody besides the POWER server guys are doing that today. So that's
> > not a strong argument in ACPI's favor. We should fix device-tree where
> > needed instead.
> Is this true.  On the Beagle Board/Bone there is extensive use of Device
> Tree Overlays, which feels like run time modification to me.  It gets 
> used to enable multiplexed pins to a particular configuration.

ACPI can load/unload an arbitrary number of SSDTs into the ACPI
namespace. They pretty much act in the same way as DT overlays. The hard
part is that the loading of an SSDT can be embedded into an AML method
so that it can be triggered by an event. I'm told that it is used for
things like hotplugging CPUs. This is what I meant in my earlier comment
that ACPI is oriented towards handling the difficult bits in the
platform. On a DT system we would describe the possible hotplugged
CPUs and expect a device driver to be present that knows when to perform
those operations.

g.

ACPI vs DT at runtime

[Jon Masters]

On Nov 15, 2013, at 12:52 PM, Olof Johansson <olof@lixom.net> wrote:

> On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
>> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
>>> The more I start to see early UEFI/ACPI code, the more I am certain
>>> that we want none of that crap in the kernel. It's making things
>>> considerably messier, while we're already very busy trying to convert
>>> everything over and enable DT -- we'll be preempting that effort just
>>> to add even more boilerplate everywhere and total progress will be
>>> hurt.
>> 
>> We are certainly under a lot of pressure with the device tree migration,
>> and I agree that adding another information source is going to be a
>> source of pain. However, I'd argue that we're going to encounter pain
>> regardless of which approach we take.
>> 
>> I'm of the opinion that the only way we should support ACPI is as a
>> first-class citizen. We don't need to modify every driver and subsystem
>> to support ACPI, only those necessary to support the minimal set of
>> platforms using ACPI. ACPI is new in the arm space, and we can enforce
>> quality standards on ACPI _now_ above what we're allowing for DT, and
>> avoid future problems.
> 
> It's obvious from the very first submission, from a vendor that has worked
> closely with "the community" (i.e. one enterprise distro at least), that this
> is completely new territory for _everyone_ involved. There's no way that we can
> enforce quality standards for ACPI yet -- we don't know what they look like!
> Nobody knows how to design a good ACPI implementation or binding.
> 
> Oh wait, there's people who have been doing this for years. Microsoft. They
> should be the ones driving this and taking the pain for it. Once the platform
> is enabled for their needs, we'll sort it out at our end. After all, that has
> worked reasonably well for x86 platforms.

For the record, Red Hat's position is to fully back ACPI on ARMv8. This is not to say that you ever will see a commercial product from Red Hat (I have nothing to say there of any kind), but in saying the above you do attempt to preclude the possibility that someone might want to ship a real Enterprise grade OS for the next few years (no offense to others who are shipping today). I would suggest a more pragmatic solution is to leverage the opportunity to be involved in the steering of ACPI on ARMv8 from the ground up, rather than just waiting for others to do it as has happened in the past (isn't that a sad reality? waiting for Microsoft to do the lifting?). It's going to happen either way. Too many silicon companies have billions on the line, and most of them are already on the ACPI train at this point - along with the major OEMs. Now if people said "sure, we'd love to join UEFI Forum but we can't afford it" or something tangible I could take back to others to secure funds or support for such involvement to proceed, then we'd be usefully advancing this :)

Jon.

ACPI vs DT at runtime

[Mark Rutland]

On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote:
> On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> > > The more I start to see early UEFI/ACPI code, the more I am certain
> > > that we want none of that crap in the kernel. It's making things
> > > considerably messier, while we're already very busy trying to convert
> > > everything over and enable DT -- we'll be preempting that effort just
> > > to add even more boilerplate everywhere and total progress will be
> > > hurt.
> >
> > We are certainly under a lot of pressure with the device tree migration,
> > and I agree that adding another information source is going to be a
> > source of pain. However, I'd argue that we're going to encounter pain
> > regardless of which approach we take.
> >
> > I'm of the opinion that the only way we should support ACPI is as a
> > first-class citizen. We don't need to modify every driver and subsystem
> > to support ACPI, only those necessary to support the minimal set of
> > platforms using ACPI. ACPI is new in the arm space, and we can enforce
> > quality standards on ACPI _now_ above what we're allowing for DT, and
> > avoid future problems.
>
> It's obvious from the very first submission, from a vendor that has worked
> closely with "the community" (i.e. one enterprise distro at least), that this
> is completely new territory for _everyone_ involved. There's no way that we can
> enforce quality standards for ACPI yet -- we don't know what they look like!
> Nobody knows how to design a good ACPI implementation or binding.

If we don't know what quality standards we require for ACPI, then I
would rather see ACPI delayed until we are more comfortable with it than
to enforce an arbitrary set of rules required to enable mapping it to
device tree.

> Oh wait, there's people who have been doing this for years. Microsoft. They
> should be the ones driving this and taking the pain for it. Once the platform
> is enabled for their needs, we'll sort it out at our end. After all, that has
> worked reasonably well for x86 platforms.

I'm not sure it's entirely reasonable to assume that Microsoft will
swoop in and develop standards that are useful to us or even applicable
to the vast majority of the systems that are likely to exist. If they
do, then we will (by the expectation that Linux should be able to run
wherever another OS can) have to support whatever standards they may
create.

Regardless of whether we place support for it into Linux, we should
certainly be spending time now attempting to understand ACPI, what it
does and does not provide, and how it can be moved towards something
that fulfils our needs and we can support long-term. We should certainly
not be taking a back seat approach.

Outside of the ARM Linux community there is work ongoing to change ACPI
to better suit the level of variation we seem in the ARM space (see
Darren Hart's presentation from ELCE [1]). We need to be involved now in
order to make sure that this is actually generally applicable.

> If we knew exactly what we wanted, it'd be a different story. _We
> don't_. We're into year FOUR of the device tree conversion and we're just
> now reaching a point where we think we know what a good solution looks
> like. The first two years were easy -- they were the trivial devices we're
> now talking about on ACPI. After that it got harder. Going through all
> of that again with ACPI? No. No way. Microsoft gets to do it and while
> they're busy sorting it out, we'll boot with device tree.

Until ACPI is able to provide all the necessary information, and has
suitable standard mechanisms for describing the horrible portions we are
only just figuring out how to describe in DT, then ACPI is eitehr no
better or worse than DT, and should not be used.

However, we should be looking into it so that when portions of it
eventually appear we have enough of an understanding to cull the
obviously broken parts.

I would also expect that _any_ ACPI support we would accept would not
rely on any board-specific support code whatsoever -- either everything
comes from ACPI or the platform doesn't boot. If we allow board files
for a transitionary period to ACPI we'd be making the same mistake we
did with DT.

> Once they're done, we'll figure out how to enable new hardware. Sure, someone
> needs to keep them sane and participate in the standardization process, but we
> don't have to drag the whole kernel through it.

To me, reworking the AML code and drivers to support AML + DT feels like
dragging the whole kernel through it. I would rather see ACPI in full or
no ACPI than a gigantic ARM-specific set of changes to general
infrastructure that we'd expect to deprecate in future once we
understand (the future state of) ACPI.

> > There may even be things which we don't have to deal with at all on ACPI
> > systems as used in servers (e.g. clock management), but perhaps we will
> > if people see value in those elements.
>
> It's not about seeing value, it's about trying to shoehorn an existing
> implementation into ACPI right now. People don't program with the ACPI
> mindset since that's not what they're used to. So everybody needs to
> re-learn everything all over again.
>
> The clock issues still have to be dealt with in ACPI _somewhere_,
> and they likely have to be dealt with by the same software team at the
> vendors that do Linux kernel work. So by forcing them to figure out how
> to do it in ACPI, we're distracting from their efforts to support their
> hardware better in the kernel in the first place. That's not win-win,
> it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft
> since they are DoS:ing us.
>
> > > The server guys really want UEFI for their boot protocols,
> > > installation managers, etc, etc. That's fine, let them do that, but
> > > that doesn't mean we need to bring the same APIs all the way into the
> > > kernel.
> > >
> > > So, I'm strongly urging that whatever the server guys try to do, it
> > > will in the end result in the ACPI data being translated into DT
> > > equivalents, such that the kernel _only_ needs to handle data via DT.
> >
> > I'm not sure that translating ACPI tables to dt makes any sense. If AML
> > is used (even sparingly), I do not believe that we can do any sensible
> > conversion to device tree. My understanding is that AML includes
> > functionality for modifying ACPI tables, and I don't see how we can
> > possibly support that without having to add a lot of boilerplate to all
> > the code handling AML to add a device tree backend...
>
> We can definitely modify device tree contents at runtime, it's just that
> nobody besides the POWER server guys are doing that today. So that's
> not a strong argument in ACPI's favor. We should fix device-tree where
> needed instead.

As mentioned above, I think that the work to do this is going to end up
as a weird ARM-specific legacy feature. We will get something wrong here
in a way that we have to support long-term. I would rather support
solely DT or solely ACPI at runtime (with a kernel supporting both),
rather than a mixture of both forever due to an artifact of the
development process.

> Also, we can either have some of our better people sort out the ACPI-to-DT
> translation and management, and get it done right, or we can rely on all the
> vendors to get ACPI right in all their drivers. While some of them will,
> I suspect we'll be more successful driving this from a common place. It
> also gives us a place to stick all the fixups for broken firmware,
> since the first generations of ARM servers are bound to have them.

This common place is going to end up handling arbitrarily different
idioms in each format (e.g. how GPIOs are represented), and is almost
certainly going to become a sprawling mess. Also having "all the fixups"
in there makes this sound like an every-single-board file, which is
something I think everyone would like to avoid.

> And best of all, it allows us to continue focus on device tree and
> getting that done right, than splitting all efforts into two. We can't
> affort that right now.
>
> > > Just like PowerPC scrapes the OpenFirmware client interface to build a
> > > flat device tree, we should add a pre-boot stage that scrapes
> > > ACPI/UEFI data and constructs an appropriate device-tree. We can still
> > > bring over ACPI methods and represent those in the DT, but we should
> > > _not_ have two native interfaces.
> >
> > I'm not sure the two cases are comparable. The format of the FDT was
> > designed to encode the data structure used by OpenFirmware, and thus the
> > two map to each other pretty well. I do not believe that mapping from
> > ACPI tables to an FDT blob is anywhere near as simple, and as I mention
> > above I do not believe that we can just copy over the ACPI methods in
> > isolation.
>
> Sorry, I wasn't implying that there's a one-time trivial conversion
> to be made in the generic case, but it can still be done in a similar
> manner even though it will be more complex.

Until I see code, I'm going to remain of the opinion that this is
unworkable without embedding knowledge of every separate subsystem
(GPIO, IRQ, etc) into a single place. That seems worse to me than
teaching those subsystems to deal with the different information
sources.

> Nobody is expecting there to be zero work for new drivers with ACPI;
> after all, the driver itself still has to be written. We're talking differences
> from board to board and system to system here, which we can definitely handle
> through a translator as well.
>
> And, as you say, if the first platforms are going to be trivial and easy to
> implement with ACPI, then doing a translation for them will be simple too.

This may be true. I worry that by working on this assumption we will
lead people to do the wrong thing by focusing on short-term gain (i.e.
placing board-specific hacks all other drivers and not handling the
general case), rather than getting a long term solution together.

> Shipping a firmware with ACPI is really no different from shipping a firmware
> with a flashed device tree. Whatever bugs or strange things the vendor chooses
> to do in there, we'll have to live with forever.
>
> We all know DT considerably better to a point where I would recommend
> that they flash a DTB in their UEFI firmware instead of go with ACPI. For
> simple hardware and basic devices we've got most bindings sorted out by
> now, and we've decided on backwards compatibility from here on out.

If a vendor does this, with a DTB that correctly describes their
hardware then I am not against it (and would prefer this case to mapping
from ACPI to DT). For that case we will also require a nailed-down boot
protocol that allows for either DTB or ACPI (only one at a time).

> > > It might be done via having a skeleton/framework DT for the vendor
> > > platform that is updated via UEFI/ACPI data, or it might be
> > > constructed entirely out of tables coming from firmware. I don't care
> > > about the methods for how it is done, but I do feel strongly that we
> > > should _not_ introduce a second API for everything. I can't think of a
> > > single good reason to do it.
> >
> > Where does this skeleton/framework come from? Within the kernel?
>
> Since there might need to be runtime modifications done to the tree based on
> ACPI events, it seems to make sense to do it in the kernel, so that translation
> state and such can be kept around for use by the runtime modification parts.
>
> Having it extractable out of the kernel tree for testing purposes would be
> greatly appreciated, so it can be ran through valgrind, add testcases, etc.

This is still sounding awfully complicated.

> > That
> > sounds like an arcane board file equivalent, and is counter to the
> > entire reason for using UEFI and ACPI -- having a well-defined
> > (excluding particular driver bindings, and I'm not arguing well-defined
> > means nice) stable standard that allows the kernel to boot on an
> > arbitrary platform without requiring arbitrary platform-specific code
> > everywhere in the boot path.
> >
> > It might not be pretty, and it will certainly require a lot of work, but
> > I'd prefer it at least for a semblance of uniformity.
>
> That is a red herring -- that booting standard has _nothing_ to do with
> ACPI. Once you've got a standard that is well-defined enough like that,
> you no longer need the runtime portions of ACPI to deal with it. You
> can just hardcode it. You need a way to probe _which_ type of standard
> is used, but from there on out you can assume that things are the same
> way.

The UEFI spec pulls in portions of ACPI. I do not know the full extent
of the interaction between the two, but I know that they are not
completely decoupled. As you have pointed out we are not experienced
with ACPI or UEFI, so I don't think we can make statements that one is
perfectly fine without the other.

> > I think that trying to shoe-horn ACPI-derived information into device
> > tree is fundamentally the wrong approach. I don't think it encourages
> > best practices, and I don't think it's beneficial to the long term
> > health of Linux or the ecosystem as a whole.
>
> There are no known best practices with ACPI. It's a complete fumbling
> around in the dark right now. We're complaining about reviewer bandwith
> on DT -- do we have a single reviewer for ACPI on ARM that actually
> knows what a good solution looks like? I don't think so.

There are many people in the Linux community who have ACPI experience.
They may not be active on the ARM side, but it's not fair to say there
are no known best practices. I will agree that for the level of
variation we're likely to expect we are pushing the boundaries.

> So, until there's strong evidence that ACPI is actually going to be
> a sane solution, in other words, until someone has shipped a system
> that uses it (with Windows) and does it successfully without being
> a hot mess, we shouldn't litter the kernel with it.

Again, I'm not sure that we should rely on Windows as our saviour from
insanity. A lot of the issues we are going to encounter are going to be
in vendor-specific code (i.e. drivers), and I do not believe that is
solved by having a single entity in charge of the general frameworks
those are built upon.

> Vendors can standardise of UEFI if they want, but I would much rather
> see them bundle DTB images with their firmware today, than rely on early
> buggy and still-early-on-the-learning-curve ACPI bindings that we then
> have to live with forever.

I agree that today a DTB is preferable to an ACPI implementation.

I think that mapping from ACPI => DT is less sane than building support
for ACPI, and is not going to help us in the long term.

I think that we need to be involved in ACPI from today if we have any
hope of having something sane in future.

Thanks,
Mark.

[1] http://events.linuxfoundation.org/sites/events/files/slides/x86-platform.pdf

ACPI vs DT at runtime

[Mark Rutland]

Hi,

> > > That
> > > sounds like an arcane board file equivalent, and is counter to the
> > > entire reason for using UEFI and ACPI -- having a well-defined
> > > (excluding particular driver bindings, and I'm not arguing well-defined
> > > means nice) stable standard that allows the kernel to boot on an
> > > arbitrary platform without requiring arbitrary platform-specific code
> > > everywhere in the boot path.
> > >
> > > It might not be pretty, and it will certainly require a lot of work, but
> > > I'd prefer it at least for a semblance of uniformity.
> >
> > That is a red herring -- that booting standard has _nothing_ to do with
> > ACPI. Once you've got a standard that is well-defined enough like that,
> > you no longer need the runtime portions of ACPI to deal with it. You
> > can just hardcode it. You need a way to probe _which_ type of standard
> > is used, but from there on out you can assume that things are the same
> > way.
> 
> The UEFI spec pulls in portions of ACPI. I do not know the full extent
> of the interaction between the two, but I know that they are not
> completely decoupled. As you have pointed out we are not experienced
> with ACPI or UEFI, so I don't think we can make statements that one is
> perfectly fine without the other.

Given Leif's comments it seems that they are decoupled sufficiently to
be considered separately.

Apologies for adding to the confusion here.

Mark.

ACPI vs DT at runtime

[Leif Lindholm]

On Tue, Nov 19, 2013 at 11:35:57AM +0000, Mark Rutland wrote:
> > The UEFI spec pulls in portions of ACPI. I do not know the full extent
> > of the interaction between the two, but I know that they are not
> > completely decoupled. As you have pointed out we are not experienced
> > with ACPI or UEFI, so I don't think we can make statements that one is
> > perfectly fine without the other.
> 
> Given Leif's comments it seems that they are decoupled sufficiently to
> be considered separately.

Well, UEFI should be considered separately from ACPI.

I am not convinced it makes sense to consider ACPI for any case that
does not also include UEFI.

/
    Leif

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Tue, Nov 19, 2013 at 11:30:15AM +0000, Mark Rutland wrote:
> I'm not sure it's entirely reasonable to assume that Microsoft will
> swoop in and develop standards that are useful to us or even applicable
> to the vast majority of the systems that are likely to exist.

It's not in their interest to do this, so it won't happen.

> Outside of the ARM Linux community there is work ongoing to change ACPI
> to better suit the level of variation we seem in the ARM space (see
> Darren Hart's presentation from ELCE [1]). We need to be involved now in
> order to make sure that this is actually generally applicable.

It may have been interesting to have attended some of these talks, but
because the LF botched up and never told the KSummit invitees that they
had free access to ELCE until after ELCE had finished...

> I think that we need to be involved in ACPI from today if we have any
> hope of having something sane in future.

I fully agree with that.  If we're not involved now, we're going to end
up with something that's already designed and implemented on systems
which we'll then _have_ no option but to accept or just not be able to
run mainline kernels on such systems.

To ignore ACPI now would be extremely n?ieve.

ACPI vs DT at runtime

[Stefano Stabellini]

On Tue, 19 Nov 2013, Mark Rutland wrote:
> > We all know DT considerably better to a point where I would recommend
> > that they flash a DTB in their UEFI firmware instead of go with ACPI. For
> > simple hardware and basic devices we've got most bindings sorted out by
> > now, and we've decided on backwards compatibility from here on out.
> 
> If a vendor does this, with a DTB that correctly describes their
> hardware then I am not against it (and would prefer this case to mapping
> from ACPI to DT).

I think that the firmware passing a DTB to the bootloader/kernel is the
best option we have.


> For that case we will also require a nailed-down boot
> protocol that allows for either DTB or ACPI.

The latest documentation patch for the "arm/arm64 UEFI boot protocol"
implies that UEFI on ARM is already capable of passing a DTB to the
kernel:

"The implementation depends on receiving information about the UEFI
environment in a Flattened Device Tree (FDT) - so is only available with
CONFIG_OF."

Maybe we just need to better document it?


> (only one at a time)

I would not go as far as requiring that only one is available.
Certainly I would mandate that either of them are independently complete
and sufficient to describe the platform.

ACPI vs DT at runtime

[Mark Rutland]

On Tue, Nov 19, 2013 at 01:56:26PM +0000, Stefano Stabellini wrote:
> On Tue, 19 Nov 2013, Mark Rutland wrote:
> > > We all know DT considerably better to a point where I would recommend
> > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For
> > > simple hardware and basic devices we've got most bindings sorted out by
> > > now, and we've decided on backwards compatibility from here on out.
> > 
> > If a vendor does this, with a DTB that correctly describes their
> > hardware then I am not against it (and would prefer this case to mapping
> > from ACPI to DT).
> 
> I think that the firmware passing a DTB to the bootloader/kernel is the
> best option we have.
> 
> 
> > For that case we will also require a nailed-down boot
> > protocol that allows for either DTB or ACPI.
> 
> The latest documentation patch for the "arm/arm64 UEFI boot protocol"
> implies that UEFI on ARM is already capable of passing a DTB to the
> kernel:
> 
> "The implementation depends on receiving information about the UEFI
> environment in a Flattened Device Tree (FDT) - so is only available with
> CONFIG_OF."
> 
> Maybe we just need to better document it?

Yes, we just need to document it.

As far as I'm aware, there are two ways we might boot the kernel:

1) Via the current boot protocol, passing a DTB in a particular
register.

2) As an EFI application. As I understand it in this case the DTB will
be saved in a system table (I may have got the terminology wrong here),
and the EFI stub will need to look it up to pass it to the kernel.

As long as that's well defined and does not preclude ACPI, then I am
happy.

> 
> 
> > (only one at a time)
> 
> I would not go as far as requiring that only one is available.
> Certainly I would mandate that either of them are independently complete
> and sufficient to describe the platform.

At that point we need to choose one to prefer. This will be a completely
arbitrary choice, but as in the EFI case we would expect a DTB stub (for
passing some options in /chosen), preferring the DT if it's more than a
stub would make sense to me.

The key point is that the kernel will rely solely on one of them to
provide hardware description.

Thanks,
Mark.

ACPI vs DT at runtime

[Leif Lindholm]

On Tue, Nov 19, 2013 at 02:38:40PM +0000, Mark Rutland wrote:
> > > For that case we will also require a nailed-down boot
> > > protocol that allows for either DTB or ACPI.
> > 
> > The latest documentation patch for the "arm/arm64 UEFI boot protocol"
> > implies that UEFI on ARM is already capable of passing a DTB to the
> > kernel:
> > 
> > "The implementation depends on receiving information about the UEFI
> > environment in a Flattened Device Tree (FDT) - so is only available with
> > CONFIG_OF."
> > 
> > Maybe we just need to better document it?
> 
> Yes, we just need to document it.

Better document it than what is currently in Booting?

> As far as I'm aware, there are two ways we might boot the kernel:
 
Nope, just one.

> 1) Via the current boot protocol, passing a DTB in a particular
> register.
 
This is the only bit relevant to the kernel proper. It does not change
with UEFI/ACPI.

> 2) As an EFI application. As I understand it in this case the DTB will
> be saved in a system table (I may have got the terminology wrong here),
> and the EFI stub will need to look it up to pass it to the kernel.
 
This applies only to the stub itself, and relates to dealing with a
firmware that provides a preloaded tree. As well as an obscurity
relating to _stub_ command line passing.

It has also not been included in the patch sets sent out so far.

> As long as that's well defined and does not preclude ACPI, then I am
> happy.

This is already well defined. I'll agree it may not be explicit enough.
If we do need any documentation changes, I feel they belong in Booting,
to explain that a minimal DT will be used even with ACPI in order _not_
to break the existing boot protocol.

/
    Leif

ACPI vs DT at runtime

[Olof Johansson]

On Tue, Nov 19, 2013 at 02:38:40PM +0000, Mark Rutland wrote:
> On Tue, Nov 19, 2013 at 01:56:26PM +0000, Stefano Stabellini wrote:

> > I would not go as far as requiring that only one is available.
> > Certainly I would mandate that either of them are independently complete
> > and sufficient to describe the platform.
> 
> At that point we need to choose one to prefer. This will be a completely
> arbitrary choice, but as in the EFI case we would expect a DTB stub (for
> passing some options in /chosen), preferring the DT if it's more than a
> stub would make sense to me.
> 
> The key point is that the kernel will rely solely on one of them to
> provide hardware description.

Given that the likley path is to have a static DT override a broken ACPI
table on a system, giving preference to DT seems like the logical choice
at this time.

There's also presendence from x86 to allow bootargs such as "noacpi" to disable
one or the other, but hopefully we can avoid that as long as possible.


-Olof

ACPI vs DT at runtime

[Arnd Bergmann]

On Tuesday 19 November 2013, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote:
> > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:

> > Oh wait, there's people who have been doing this for years. Microsoft. They
> > should be the ones driving this and taking the pain for it. Once the platform
> > is enabled for their needs, we'll sort it out at our end. After all, that has
> > worked reasonably well for x86 platforms.
> 
> I'm not sure it's entirely reasonable to assume that Microsoft will
> swoop in and develop standards that are useful to us or even applicable
> to the vast majority of the systems that are likely to exist. If they
> do, then we will (by the expectation that Linux should be able to run
> wherever another OS can) have to support whatever standards they may
> create.

That company is undergoing a lot of change now, I think anything is
possible: They might decide that ARM is a really bad idea (after
the Windows-RT fiasco), they could start working together with us
on these problems, or they could do everything in their hands to
make our lives as hard as they can (as before, see
http://www.groklaw.net/articlebasic.php?story=2010011422570951).
 
> Regardless of whether we place support for it into Linux, we should
> certainly be spending time now attempting to understand ACPI, what it
> does and does not provide, and how it can be moved towards something
> that fulfils our needs and we can support long-term. We should certainly
> not be taking a back seat approach.
>
> Outside of the ARM Linux community there is work ongoing to change ACPI
> to better suit the level of variation we seem in the ARM space (see
> Darren Hart's presentation from ELCE [1]). We need to be involved now in
> order to make sure that this is actually generally applicable.

Agreed. I'm not sure who "we" is in this, but I assume you mean the wider
ARM Linux developer community.  Linaro already has full-time developers
working on this, with ties into the UEFI and ACPI standard bodies, and that
is good. Still it does not mean we should prematurely merge any of the
code coming out of it, until there are products out there with ACPI firmware
that is not completely messed up and that is worth supporting in mainline,
considering the maintainance effort.

> I would also expect that _any_ ACPI support we would accept would not
> rely on any board-specific support code whatsoever -- either everything
> comes from ACPI or the platform doesn't boot. If we allow board files
> for a transitionary period to ACPI we'd be making the same mistake we
> did with DT.

I would go further and reject any code that adds an SoC or BIOS vendor
specific glue layer. The bar we have set with the current ARM64 code
and for new ARM32 is that everything is in device drivers of some sort.
I would hate to reintroduce platform directories just because every
company has a different understanding of how to describe the same things
in ACPI, or because ACPI-5.0 is insufficient to describe the SoC and
go back to static platform devices.

> > Once they're done, we'll figure out how to enable new hardware. Sure, someone
> > needs to keep them sane and participate in the standardization process, but we
> > don't have to drag the whole kernel through it.
> 
> To me, reworking the AML code and drivers to support AML + DT feels like
> dragging the whole kernel through it. I would rather see ACPI in full or
> no ACPI than a gigantic ARM-specific set of changes to general
> infrastructure that we'd expect to deprecate in future once we
> understand (the future state of) ACPI.

I'm skeptical about getting AML working on DT nodes, just as I doubt that
AML is sufficient to do what people want when faced with a complex SoC.

Also, if AML ends up being mainly used as a trampoline to get into EL2/EL3
firmware, I'd much rather standardize the actual firmware interfaces
underneath.
 
> As mentioned above, I think that the work to do this is going to end up
> as a weird ARM-specific legacy feature. We will get something wrong here
> in a way that we have to support long-term. I would rather support
> solely DT or solely ACPI at runtime (with a kernel supporting both),
> rather than a mixture of both forever due to an artifact of the
> development process.

I think that depends on how whether you expect ACPI to succeed in the market
or not. If it ends up being a historic sidenote, that's what the code
should be.
A precedent for this would be mach-shark, which we just removed. It
was one of the original StrongARM machines and actually came with Open
Firmware and a DT that was (rightfully so) converted to ATAGS format
on boot.
 
> > Also, we can either have some of our better people sort out the ACPI-to-DT
> > translation and management, and get it done right, or we can rely on all the
> > vendors to get ACPI right in all their drivers. While some of them will,
> > I suspect we'll be more successful driving this from a common place. It
> > also gives us a place to stick all the fixups for broken firmware,
> > since the first generations of ARM servers are bound to have them.
> 
> This common place is going to end up handling arbitrarily different
> idioms in each format (e.g. how GPIOs are represented), and is almost
> certainly going to become a sprawling mess. Also having "all the fixups"
> in there makes this sound like an every-single-board file, which is
> something I think everyone would like to avoid.

I guess if it grows too big, it could be moved into a separate boot loader
project and out of the kernel, as we do for the ATAGS-to-DT conversion
with the impedence-matcher.

> > > I'm not sure the two cases are comparable. The format of the FDT was
> > > designed to encode the data structure used by OpenFirmware, and thus the
> > > two map to each other pretty well. I do not believe that mapping from
> > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention
> > > above I do not believe that we can just copy over the ACPI methods in
> > > isolation.
> >
> > Sorry, I wasn't implying that there's a one-time trivial conversion
> > to be made in the generic case, but it can still be done in a similar
> > manner even though it will be more complex.
> 
> Until I see code, I'm going to remain of the opinion that this is
> unworkable without embedding knowledge of every separate subsystem
> (GPIO, IRQ, etc) into a single place. That seems worse to me than
> teaching those subsystems to deal with the different information
> sources.

Agreed.

> > Vendors can standardise of UEFI if they want, but I would much rather
> > see them bundle DTB images with their firmware today, than rely on early
> > buggy and still-early-on-the-learning-curve ACPI bindings that we then
> > have to live with forever.
> 
> I agree that today a DTB is preferable to an ACPI implementation.
> 
> I think that mapping from ACPI => DT is less sane than building support
> for ACPI, and is not going to help us in the long term.
> 
> I think that we need to be involved in ACPI from today if we have any
> hope of having something sane in future.

I mostly agree, but I think that the decision whether to ignore, translate
or implement support for ACPI BIOS implementations depends a lot on
what kinds of systems we are going to see and the level of sophistication
they put into their firmware.

If we are basically talking about PCs with their x86 CPU removed and
an ARM chip put in there, I think an ACPI implementation would be
harmless enough. However if we are talking about complex SoCs that just
have the same information in ACPI that we have in DT in a different
format, we really need to tell the responsible developers that ACPI
support for these just won't get merged.

	Arnd

ACPI vs DT at runtime

[Mark Rutland]

On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote:
> On Tuesday 19 November 2013, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote:
> > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> 
> > > Oh wait, there's people who have been doing this for years. Microsoft. They
> > > should be the ones driving this and taking the pain for it. Once the platform
> > > is enabled for their needs, we'll sort it out at our end. After all, that has
> > > worked reasonably well for x86 platforms.
> > 
> > I'm not sure it's entirely reasonable to assume that Microsoft will
> > swoop in and develop standards that are useful to us or even applicable
> > to the vast majority of the systems that are likely to exist. If they
> > do, then we will (by the expectation that Linux should be able to run
> > wherever another OS can) have to support whatever standards they may
> > create.
> 
> That company is undergoing a lot of change now, I think anything is
> possible: They might decide that ARM is a really bad idea (after
> the Windows-RT fiasco), they could start working together with us
> on these problems, or they could do everything in their hands to
> make our lives as hard as they can (as before, see
> http://www.groklaw.net/articlebasic.php?story=2010011422570951).
>  
> > Regardless of whether we place support for it into Linux, we should
> > certainly be spending time now attempting to understand ACPI, what it
> > does and does not provide, and how it can be moved towards something
> > that fulfils our needs and we can support long-term. We should certainly
> > not be taking a back seat approach.
> >
> > Outside of the ARM Linux community there is work ongoing to change ACPI
> > to better suit the level of variation we seem in the ARM space (see
> > Darren Hart's presentation from ELCE [1]). We need to be involved now in
> > order to make sure that this is actually generally applicable.
> 
> Agreed. I'm not sure who "we" is in this, but I assume you mean the wider
> ARM Linux developer community.  Linaro already has full-time developers
> working on this, with ties into the UEFI and ACPI standard bodies, and that
> is good. Still it does not mean we should prematurely merge any of the
> code coming out of it, until there are products out there with ACPI firmware
> that is not completely messed up and that is worth supporting in mainline,
> considering the maintainance effort.

Yes, I meant the greater ARM Linux community. I'm aware that Linaro have
people working full-time on this, but we still need members of the
greater community to become familiar with ACPI and have an input on it
before the greater community can realistically expect to support it.

> 
> > I would also expect that _any_ ACPI support we would accept would not
> > rely on any board-specific support code whatsoever -- either everything
> > comes from ACPI or the platform doesn't boot. If we allow board files
> > for a transitionary period to ACPI we'd be making the same mistake we
> > did with DT.
> 
> I would go further and reject any code that adds an SoC or BIOS vendor
> specific glue layer. The bar we have set with the current ARM64 code
> and for new ARM32 is that everything is in device drivers of some sort.
> I would hate to reintroduce platform directories just because every
> company has a different understanding of how to describe the same things
> in ACPI, or because ACPI-5.0 is insufficient to describe the SoC and
> go back to static platform devices.

Agreed.

> > > Once they're done, we'll figure out how to enable new hardware. Sure, someone
> > > needs to keep them sane and participate in the standardization process, but we
> > > don't have to drag the whole kernel through it.
> > 
> > To me, reworking the AML code and drivers to support AML + DT feels like
> > dragging the whole kernel through it. I would rather see ACPI in full or
> > no ACPI than a gigantic ARM-specific set of changes to general
> > infrastructure that we'd expect to deprecate in future once we
> > understand (the future state of) ACPI.
> 
> I'm skeptical about getting AML working on DT nodes, just as I doubt that
> AML is sufficient to do what people want when faced with a complex SoC.
> 
> Also, if AML ends up being mainly used as a trampoline to get into EL2/EL3
> firmware, I'd much rather standardize the actual firmware interfaces
> underneath.

Agreed. I currently hope that any firmware interfaces for (CPU) power
management will be PSCI compatible.

>  
> > As mentioned above, I think that the work to do this is going to end up
> > as a weird ARM-specific legacy feature. We will get something wrong here
> > in a way that we have to support long-term. I would rather support
> > solely DT or solely ACPI at runtime (with a kernel supporting both),
> > rather than a mixture of both forever due to an artifact of the
> > development process.
> 
> I think that depends on how whether you expect ACPI to succeed in the market
> or not. If it ends up being a historic sidenote, that's what the code
> should be.
> A precedent for this would be mach-shark, which we just removed. It
> was one of the original StrongARM machines and actually came with Open
> Firmware and a DT that was (rightfully so) converted to ATAGS format
> on boot.

>From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the
converter only converted /memory, /chosen/bootargs, and /banner-name.
That's far less complex than converting an arbitrary ACPI table, and far
less likely to hold subtle quirks that vendors will begin relying on in
their firmware. It also looks like it could have been factored out were
there more OpenFirmware systems.

I think that with ACPI systems the data we would have to convert is
going to be larger and more varied than that. Given we already have code
in the kernel for handling ACPI, I believe it would be more valuable to
leverage that and support ACPI directly in those places which require it

>  
> > > Also, we can either have some of our better people sort out the ACPI-to-DT
> > > translation and management, and get it done right, or we can rely on all the
> > > vendors to get ACPI right in all their drivers. While some of them will,
> > > I suspect we'll be more successful driving this from a common place. It
> > > also gives us a place to stick all the fixups for broken firmware,
> > > since the first generations of ARM servers are bound to have them.
> > 
> > This common place is going to end up handling arbitrarily different
> > idioms in each format (e.g. how GPIOs are represented), and is almost
> > certainly going to become a sprawling mess. Also having "all the fixups"
> > in there makes this sound like an every-single-board file, which is
> > something I think everyone would like to avoid.
> 
> I guess if it grows too big, it could be moved into a separate boot loader
> project and out of the kernel, as we do for the ATAGS-to-DT conversion
> with the impedence-matcher.

I think there's a big difference between the impedence matcher and the
proposed ACPI => DT converter. The impedence matcher maps a well-defined
unique ID to a binary blob it knows nothing about. The proposed ACPI =>
DT converter necessarily needs to map differing idioms used to represent
classes of device, and thus picks up all the domain-specific knowledge
that would otherwise be part of a particular subsystem (e.g. GPIO), or
even drivers depending on the granularity of conversion.

To me it seems that placing this in an external blob is fundamentally
the wrong way to go. It must necessarily lump together various
unconnected concerns, and will end up mirroring the structure of Linux
subsystems and drivers. I think by the time it "grows too big", we've
already lost, having wasted our time putting something together that
should have been handled in Linux from the start.

> 
> > > > I'm not sure the two cases are comparable. The format of the FDT was
> > > > designed to encode the data structure used by OpenFirmware, and thus the
> > > > two map to each other pretty well. I do not believe that mapping from
> > > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention
> > > > above I do not believe that we can just copy over the ACPI methods in
> > > > isolation.
> > >
> > > Sorry, I wasn't implying that there's a one-time trivial conversion
> > > to be made in the generic case, but it can still be done in a similar
> > > manner even though it will be more complex.
> > 
> > Until I see code, I'm going to remain of the opinion that this is
> > unworkable without embedding knowledge of every separate subsystem
> > (GPIO, IRQ, etc) into a single place. That seems worse to me than
> > teaching those subsystems to deal with the different information
> > sources.
> 
> Agreed.
> 
> > > Vendors can standardise of UEFI if they want, but I would much rather
> > > see them bundle DTB images with their firmware today, than rely on early
> > > buggy and still-early-on-the-learning-curve ACPI bindings that we then
> > > have to live with forever.
> > 
> > I agree that today a DTB is preferable to an ACPI implementation.
> > 
> > I think that mapping from ACPI => DT is less sane than building support
> > for ACPI, and is not going to help us in the long term.
> > 
> > I think that we need to be involved in ACPI from today if we have any
> > hope of having something sane in future.
> 
> I mostly agree, but I think that the decision whether to ignore, translate
> or implement support for ACPI BIOS implementations depends a lot on
> what kinds of systems we are going to see and the level of sophistication
> they put into their firmware.
> 
> If we are basically talking about PCs with their x86 CPU removed and
> an ARM chip put in there, I think an ACPI implementation would be
> harmless enough. However if we are talking about complex SoCs that just
> have the same information in ACPI that we have in DT in a different
> format, we really need to tell the responsible developers that ACPI
> support for these just won't get merged.

I mostly agree. However, I'm not so sure on the latter case. If ACPI
matures support for richer description (as some x86 people are pushing
for) and it's used in a sane manner, then I don't think we should
prevent that, especially if the maintenance burden is shared by the
larger Linux community.

Thanks,
Mark.

ACPI vs DT at runtime

[Arnd Bergmann]

On Tuesday 19 November 2013, Mark Rutland wrote:
> On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote:
> > > As mentioned above, I think that the work to do this is going to end up
> > > as a weird ARM-specific legacy feature. We will get something wrong here
> > > in a way that we have to support long-term. I would rather support
> > > solely DT or solely ACPI at runtime (with a kernel supporting both),
> > > rather than a mixture of both forever due to an artifact of the
> > > development process.
> > 
> > I think that depends on how whether you expect ACPI to succeed in the market
> > or not. If it ends up being a historic sidenote, that's what the code
> > should be.
> > A precedent for this would be mach-shark, which we just removed. It
> > was one of the original StrongARM machines and actually came with Open
> > Firmware and a DT that was (rightfully so) converted to ATAGS format
> > on boot.
> 
> From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the
> converter only converted /memory, /chosen/bootargs, and /banner-name.
> That's far less complex than converting an arbitrary ACPI table, and far
> less likely to hold subtle quirks that vendors will begin relying on in
> their firmware. It also looks like it could have been factored out were
> there more OpenFirmware systems.

Right. Of course at the time, things were much simpler in general.

> I think that with ACPI systems the data we would have to convert is
> going to be larger and more varied than that. Given we already have code
> in the kernel for handling ACPI, I believe it would be more valuable to
> leverage that and support ACPI directly in those places which require it

We have code in the kernel to handle power management and a couple of
very specific platform devices on ACPI based x86 and Itanium PCs. We would
use very little of that on ARM, and it doesn't do much of what we need
at the moment. We definitely shouldn't add all that infrastructure to
make it work on ARM just because someone accidentally put four letters into
a requirements document and didn't understand the consequences...

> > > > Also, we can either have some of our better people sort out the ACPI-to-DT
> > > > translation and management, and get it done right, or we can rely on all the
> > > > vendors to get ACPI right in all their drivers. While some of them will,
> > > > I suspect we'll be more successful driving this from a common place. It
> > > > also gives us a place to stick all the fixups for broken firmware,
> > > > since the first generations of ARM servers are bound to have them.
> > > 
> > > This common place is going to end up handling arbitrarily different
> > > idioms in each format (e.g. how GPIOs are represented), and is almost
> > > certainly going to become a sprawling mess. Also having "all the fixups"
> > > in there makes this sound like an every-single-board file, which is
> > > something I think everyone would like to avoid.
> > 
> > I guess if it grows too big, it could be moved into a separate boot loader
> > project and out of the kernel, as we do for the ATAGS-to-DT conversion
> > with the impedence-matcher.
> 
> I think there's a big difference between the impedence matcher and the
> proposed ACPI => DT converter. The impedence matcher maps a well-defined
> unique ID to a binary blob it knows nothing about. The proposed ACPI =>
> DT converter necessarily needs to map differing idioms used to represent
> classes of device, and thus picks up all the domain-specific knowledge
> that would otherwise be part of a particular subsystem (e.g. GPIO), or
> even drivers depending on the granularity of conversion.
> 
> To me it seems that placing this in an external blob is fundamentally
> the wrong way to go. It must necessarily lump together various
> unconnected concerns, and will end up mirroring the structure of Linux
> subsystems and drivers. I think by the time it "grows too big", we've
> already lost, having wasted our time putting something together that
> should have been handled in Linux from the start.

As I said, it really depends on what people actually want to do with
ACPI, and why they want it. I can see some scenarios in which it would
be fairly easy to do the conversion, such as when all the devices are
fixed in the SoC and you just need to map a couple of GPIO lines
or I2C devices. Doing the full conversion of an SoC structure otoh
would be pretty crazy.

> > > > Vendors can standardise of UEFI if they want, but I would much rather
> > > > see them bundle DTB images with their firmware today, than rely on early
> > > > buggy and still-early-on-the-learning-curve ACPI bindings that we then
> > > > have to live with forever.
> > > 
> > > I agree that today a DTB is preferable to an ACPI implementation.
> > > 
> > > I think that mapping from ACPI => DT is less sane than building support
> > > for ACPI, and is not going to help us in the long term.
> > > 
> > > I think that we need to be involved in ACPI from today if we have any
> > > hope of having something sane in future.
> > 
> > I mostly agree, but I think that the decision whether to ignore, translate
> > or implement support for ACPI BIOS implementations depends a lot on
> > what kinds of systems we are going to see and the level of sophistication
> > they put into their firmware.
> > 
> > If we are basically talking about PCs with their x86 CPU removed and
> > an ARM chip put in there, I think an ACPI implementation would be
> > harmless enough. However if we are talking about complex SoCs that just
> > have the same information in ACPI that we have in DT in a different
> > format, we really need to tell the responsible developers that ACPI
> > support for these just won't get merged.
> 
> I mostly agree. However, I'm not so sure on the latter case. If ACPI
> matures support for richer description (as some x86 people are pushing
> for) and it's used in a sane manner, then I don't think we should
> prevent that, especially if the maintenance burden is shared by the
> larger Linux community.

True, I just think that's too many "if"s to build a product roadmap on.
It can turn into that in a couple of years, but anyone building a
complex SoC today is better off assuming it won't come to that IMHO.

	Arnd

ACPI vs DT at runtime

[Olof Johansson]

On Tue, Nov 19, 2013 at 03:21:57PM +0000, Mark Rutland wrote:
> On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote:
> > On Tuesday 19 November 2013, Mark Rutland wrote:
> > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote:
> > > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> > 
> > > > Oh wait, there's people who have been doing this for years. Microsoft. They
> > > > should be the ones driving this and taking the pain for it. Once the platform
> > > > is enabled for their needs, we'll sort it out at our end. After all, that has
> > > > worked reasonably well for x86 platforms.
> > > 
> > > I'm not sure it's entirely reasonable to assume that Microsoft will
> > > swoop in and develop standards that are useful to us or even applicable
> > > to the vast majority of the systems that are likely to exist. If they
> > > do, then we will (by the expectation that Linux should be able to run
> > > wherever another OS can) have to support whatever standards they may
> > > create.
> > 
> > That company is undergoing a lot of change now, I think anything is
> > possible: They might decide that ARM is a really bad idea (after
> > the Windows-RT fiasco), they could start working together with us
> > on these problems, or they could do everything in their hands to
> > make our lives as hard as they can (as before, see
> > http://www.groklaw.net/articlebasic.php?story=2010011422570951).
> >  
> > > Regardless of whether we place support for it into Linux, we should
> > > certainly be spending time now attempting to understand ACPI, what it
> > > does and does not provide, and how it can be moved towards something
> > > that fulfils our needs and we can support long-term. We should certainly
> > > not be taking a back seat approach.
> > >
> > > Outside of the ARM Linux community there is work ongoing to change ACPI
> > > to better suit the level of variation we seem in the ARM space (see
> > > Darren Hart's presentation from ELCE [1]). We need to be involved now in
> > > order to make sure that this is actually generally applicable.
> > 
> > Agreed. I'm not sure who "we" is in this, but I assume you mean the wider
> > ARM Linux developer community.  Linaro already has full-time developers
> > working on this, with ties into the UEFI and ACPI standard bodies, and that
> > is good. Still it does not mean we should prematurely merge any of the
> > code coming out of it, until there are products out there with ACPI firmware
> > that is not completely messed up and that is worth supporting in mainline,
> > considering the maintainance effort.
> 
> Yes, I meant the greater ARM Linux community. I'm aware that Linaro have
> people working full-time on this, but we still need members of the
> greater community to become familiar with ACPI and have an input on it
> before the greater community can realistically expect to support it.

Getting people to join straight from "the community" isn't likely. Or
if people join, it might not be the people you actually need. It's
more likely that people involved both with upstream and other things
at various vendors will join and try to keep things sane.

However, given that UEFI/ACPI is a standards body, the number of actual
software engineers interested in participating in such activity might
be small.

> > I mostly agree, but I think that the decision whether to ignore, translate
> > or implement support for ACPI BIOS implementations depends a lot on
> > what kinds of systems we are going to see and the level of sophistication
> > they put into their firmware.
> > 
> > If we are basically talking about PCs with their x86 CPU removed and
> > an ARM chip put in there, I think an ACPI implementation would be
> > harmless enough. However if we are talking about complex SoCs that just
> > have the same information in ACPI that we have in DT in a different
> > format, we really need to tell the responsible developers that ACPI
> > support for these just won't get merged.
> 
> I mostly agree. However, I'm not so sure on the latter case. If ACPI
> matures support for richer description (as some x86 people are pushing
> for) and it's used in a sane manner, then I don't think we should
> prevent that, especially if the maintenance burden is shared by the
> larger Linux community.

Imposing a maintenance burden on a larger set of users is the completely
wrong way to do this.

I'm hoping what you're meaning to say is that we can share infrastructure
and solutions between the various architectures, which is a completely
different thing than imposing our maintenance on them. :)

Still, I'm with Arnd here: It's not a given at this time that we'll ever
enable ACPI across the board. For the short-to-medium term it certainly
seems like a bad idea to bring in much code for it, and for the longer
term we don't know yet. For a vendor, it's safer to plan for both --
and if you don't care about RT compatibility focus on DT today (but keep
an eye on ACPI developments).


-Olof

ACPI vs DT at runtime

[Tom Rini]

On Tue, Nov 19, 2013 at 03:21:57PM +0000, Mark Rutland wrote:
[snip]
> I think that with ACPI systems the data we would have to convert is
> going to be larger and more varied than that. Given we already have code
> in the kernel for handling ACPI, I believe it would be more valuable to
> leverage that and support ACPI directly in those places which require it

I'll bite.  How realistic a proprosition is that?  When I've talked with
a few folks here and there they say, roughly, that "the ARM bit" being
set means it's a whole new ball game, and no, they don't expect to be
able to re-use a lot of the existing code.

-- 
Tom

ACPI vs DT at runtime

[Olof Johansson]

On Tue, Nov 19, 2013 at 11:30:15AM +0000, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote:
> > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> > > > The more I start to see early UEFI/ACPI code, the more I am certain
> > > > that we want none of that crap in the kernel. It's making things
> > > > considerably messier, while we're already very busy trying to convert
> > > > everything over and enable DT -- we'll be preempting that effort just
> > > > to add even more boilerplate everywhere and total progress will be
> > > > hurt.
> > >
> > > We are certainly under a lot of pressure with the device tree migration,
> > > and I agree that adding another information source is going to be a
> > > source of pain. However, I'd argue that we're going to encounter pain
> > > regardless of which approach we take.
> > >
> > > I'm of the opinion that the only way we should support ACPI is as a
> > > first-class citizen. We don't need to modify every driver and subsystem
> > > to support ACPI, only those necessary to support the minimal set of
> > > platforms using ACPI. ACPI is new in the arm space, and we can enforce
> > > quality standards on ACPI _now_ above what we're allowing for DT, and
> > > avoid future problems.
> >
> > It's obvious from the very first submission, from a vendor that has worked
> > closely with "the community" (i.e. one enterprise distro at least), that this
> > is completely new territory for _everyone_ involved. There's no way that we can
> > enforce quality standards for ACPI yet -- we don't know what they look like!
> > Nobody knows how to design a good ACPI implementation or binding.
> 
> If we don't know what quality standards we require for ACPI, then I
> would rather see ACPI delayed until we are more comfortable with it than
> to enforce an arbitrary set of rules required to enable mapping it to
> device tree.

That's essentially what we're saying here: ACPI isn't ready, let's use DT while
it's sorted out and if someone wants to try to require ACPI at some level
today, they should figure out how to translate it into DT. In reality, it might
be easiest to ship a static DT file while ACPI is being developed and sorted
out.

I think we're getting bogged down by the hypothetical AML-in-DT case. We won't
know if we want/need it until we see what kind of stuff vendors think they will
need to do in AML. On x86 it's mostly used to abstract out per-board
differences, not whole SoC behavior. It also depends on how much of their
hardware differences the silicon vendors decide to punt to software to manage
-- that's going to work a lot less well in this type of environment than it
does on 32-bit today.

> > Oh wait, there's people who have been doing this for years. Microsoft. They
> > should be the ones driving this and taking the pain for it. Once the platform
> > is enabled for their needs, we'll sort it out at our end. After all, that has
> > worked reasonably well for x86 platforms.
> 
> I'm not sure it's entirely reasonable to assume that Microsoft will
> swoop in and develop standards that are useful to us or even applicable
> to the vast majority of the systems that are likely to exist. If they
> do, then we will (by the expectation that Linux should be able to run
> wherever another OS can) have to support whatever standards they may
> create.
> 
> Regardless of whether we place support for it into Linux, we should
> certainly be spending time now attempting to understand ACPI, what it
> does and does not provide, and how it can be moved towards something
> that fulfils our needs and we can support long-term. We should certainly
> not be taking a back seat approach.
> 
> Outside of the ARM Linux community there is work ongoing to change ACPI
> to better suit the level of variation we seem in the ARM space (see
> Darren Hart's presentation from ELCE [1]). We need to be involved now in
> order to make sure that this is actually generally applicable.

I agree that there should be engagement, but not at the expense of forward
progress using the technologies we're finally sorting out how to use
successfully. In other words, we should continue enabling DT on these
platforms while ACPI happens in the background for now. People who
will longer-term depend on ACPI should of course get engaged in that,
but things aren't going to work well if they?abandon working on the
short-to-medium term solutions of continued DT usage.

> > If we knew exactly what we wanted, it'd be a different story. _We
> > don't_. We're into year FOUR of the device tree conversion and we're just
> > now reaching a point where we think we know what a good solution looks
> > like. The first two years were easy -- they were the trivial devices we're
> > now talking about on ACPI. After that it got harder. Going through all
> > of that again with ACPI? No. No way. Microsoft gets to do it and while
> > they're busy sorting it out, we'll boot with device tree.
> 
> Until ACPI is able to provide all the necessary information, and has
> suitable standard mechanisms for describing the horrible portions we are
> only just figuring out how to describe in DT, then ACPI is eitehr no
> better or worse than DT, and should not be used.
> 
> However, we should be looking into it so that when portions of it
> eventually appear we have enough of an understanding to cull the
> obviously broken parts.

I think we're in full agreement on this.

> I would also expect that _any_ ACPI support we would accept would not
> rely on any board-specific support code whatsoever -- either everything
> comes from ACPI or the platform doesn't boot. If we allow board files
> for a transitionary period to ACPI we'd be making the same mistake we
> did with DT.

I don't think anyone is arguing for board files here, that's a dead end. :-)
There might however be quirks needed for drivers here and there, at least for
new platforms (chipsets), errata workarounds, etc. That's expected, and it's
something that they need on x86 today as well.

> > Once they're done, we'll figure out how to enable new hardware. Sure, someone
> > needs to keep them sane and participate in the standardization process, but we
> > don't have to drag the whole kernel through it.
> 
> To me, reworking the AML code and drivers to support AML + DT feels like
> dragging the whole kernel through it. I would rather see ACPI in full or
> no ACPI than a gigantic ARM-specific set of changes to general
> infrastructure that we'd expect to deprecate in future once we
> understand (the future state of) ACPI.

I think we're getting bogged down in details here, unfortunately. Let's see
what people have in mind to implement in AML before we go too far down this
path. In theory it could be a nightmare to deal with it given the feature set
and complexity of AML, but in reality chances are we can do quite well with
just device-tree (as Arnd and others have been arguing as well).

So I think we can postpone much of this debate until we actually have examples
of what people will use in the real world.


[pruning out some double quotes and more AML-related arguments here]


> > Also, we can either have some of our better people sort out the ACPI-to-DT
> > translation and management, and get it done right, or we can rely on all the
> > vendors to get ACPI right in all their drivers. While some of them will,
> > I suspect we'll be more successful driving this from a common place. It
> > also gives us a place to stick all the fixups for broken firmware,
> > since the first generations of ARM servers are bound to have them.
> 
> This common place is going to end up handling arbitrarily different
> idioms in each format (e.g. how GPIOs are represented), and is almost
> certainly going to become a sprawling mess. Also having "all the fixups"
> in there makes this sound like an every-single-board file, which is
> something I think everyone would like to avoid.

Yeah, it would need to be generic enough to not require per-board changes.
Again, let's see how things turn out in reality before we go too far down that
path, doing it on theoretical needs is going to overly complicate things.

[...]

> > Nobody is expecting there to be zero work for new drivers with ACPI;
> > after all, the driver itself still has to be written. We're talking differences
> > from board to board and system to system here, which we can definitely handle
> > through a translator as well.
> >
> > And, as you say, if the first platforms are going to be trivial and easy to
> > implement with ACPI, then doing a translation for them will be simple too.
> 
> This may be true. I worry that by working on this assumption we will
> lead people to do the wrong thing by focusing on short-term gain (i.e.
> placing board-specific hacks all other drivers and not handling the
> general case), rather than getting a long term solution together.

There's going to be need for both, and we can't sacrifice work on the
short-to-medium term solution because I really don't want things to
stumble right away. As Jon is saying, lots of companies are spending
significant resources on this, and we need to make sure things are as
successful as possible right out the door.

That means not restricting short-term solutions with promises/wishes/hopes
that things will magically get sorted out by themselves down the
road. Given the initial output from the ACPI side of things, that's way
too scary a bet to make.

> > Shipping a firmware with ACPI is really no different from shipping a firmware
> > with a flashed device tree. Whatever bugs or strange things the vendor chooses
> > to do in there, we'll have to live with forever.
> >
> > We all know DT considerably better to a point where I would recommend
> > that they flash a DTB in their UEFI firmware instead of go with ACPI. For
> > simple hardware and basic devices we've got most bindings sorted out by
> > now, and we've decided on backwards compatibility from here on out.
> 
> If a vendor does this, with a DTB that correctly describes their
> hardware then I am not against it (and would prefer this case to mapping
> from ACPI to DT). For that case we will also require a nailed-down boot
> protocol that allows for either DTB or ACPI (only one at a time).

UEFI already allows this, as far as I know? Even if both are passed, we can
easily make DT take precedence over ACPI, just like DT overrides ATAGs today.

> > > > It might be done via having a skeleton/framework DT for the vendor
> > > > platform that is updated via UEFI/ACPI data, or it might be
> > > > constructed entirely out of tables coming from firmware. I don't care
> > > > about the methods for how it is done, but I do feel strongly that we
> > > > should _not_ introduce a second API for everything. I can't think of a
> > > > single good reason to do it.
> > >
> > > Where does this skeleton/framework come from? Within the kernel?
> >
> > Since there might need to be runtime modifications done to the tree based on
> > ACPI events, it seems to make sense to do it in the kernel, so that translation
> > state and such can be kept around for use by the runtime modification parts.
> >
> > Having it extractable out of the kernel tree for testing purposes would be
> > greatly appreciated, so it can be ran through valgrind, add testcases, etc.
> 
> This is still sounding awfully complicated.

Yes, but so is doing a native ACPI implementation. Anyway, let's hold off until
we know what we're actually going to need.

> > There are no known best practices with ACPI. It's a complete fumbling
> > around in the dark right now. We're complaining about reviewer bandwith
> > on DT -- do we have a single reviewer for ACPI on ARM that actually
> > knows what a good solution looks like? I don't think so.
> 
> There are many people in the Linux community who have ACPI experience.
> They may not be active on the ARM side, but it's not fair to say there
> are no known best practices. I will agree that for the level of
> variation we're likely to expect we are pushing the boundaries.

Right -- as we've seen with DT where it was easy-peasy on PowerPC since there
were only 2-4 real vendors involved, things get substantially more complicated
when you increase that by an order of magnitude. In this case, we'd be
increasing it with an order of magnitude _and_ bring in their firmware
engineers to be involved too (since we would no longer have control over what
gets put into the tables).

While there are people who have a lot of ACPI experience today, the environment
around it (community/participants and technical diversity) _and_ the new need
for more complex things is new to everybody. As we've seen with DT, we can't
always rely on the existing people to have capacity for the onslaught of
activity that will come down the pipe.

> > So, until there's strong evidence that ACPI is actually going to be
> > a sane solution, in other words, until someone has shipped a system
> > that uses it (with Windows) and does it successfully without being
> > a hot mess, we shouldn't litter the kernel with it.
> 
> Again, I'm not sure that we should rely on Windows as our saviour from
> insanity. A lot of the issues we are going to encounter are going to be
> in vendor-specific code (i.e. drivers), and I do not believe that is
> solved by having a single entity in charge of the general frameworks
> those are built upon.

As mentioned in other replies in the thread, I was a bit careless in how
I phrased this. We can't just wait until they're done, but we also shouldn't
do it all ourselves. And we definitely shouldn't bet our house on it resulting
in a useable solution at this point.

> > Vendors can standardise of UEFI if they want, but I would much rather
> > see them bundle DTB images with their firmware today, than rely on early
> > buggy and still-early-on-the-learning-curve ACPI bindings that we then
> > have to live with forever.
> 
> I agree that today a DTB is preferable to an ACPI implementation.
> 
> I think that mapping from ACPI => DT is less sane than building support
> for ACPI, and is not going to help us in the long term.

I think it'll depend on what will actually be needed on real systems. And
I'm not making many assumptions on long term here -- we can't let that
distract us from getting the first few years sorted out first.

> I think that we need to be involved in ACPI from today if we have any
> hope of having something sane in future.

We agree more than we disagree on this whole discussion, I believe.


-Olof

ACPI vs DT at runtime

[Grant Likely]

On Tue, 19 Nov 2013 10:19:59 -0800, Olof Johansson <olof@lixom.net> wrote:
> I think we're getting bogged down by the hypothetical AML-in-DT case. We won't
> know if we want/need it until we see what kind of stuff vendors think they will
> need to do in AML. On x86 it's mostly used to abstract out per-board
> differences, not whole SoC behavior. It also depends on how much of their
> hardware differences the silicon vendors decide to punt to software to manage
> -- that's going to work a lot less well in this type of environment than it
> does on 32-bit today.

I'm going to go out on a limb here and say flat out "no" to AML in DT.
AML in DT makes no sense to me. I've resisted any attempts to add a
bytecode to FDT. The whole model we've been working on with DT is
describe the hardware as competently as possible and expect device
drivers to bind on the platform to handle the fiddly bits. ACPI takes
the opposite approach and I don't want to go down the path of pushing
functionality out to the platform when using the DT infrastructure.

... That said, I'm not opposed to the ACPI and DT subsystems making use
of shared infrastructure wherever possible.

> > If a vendor does this, with a DTB that correctly describes their
> > hardware then I am not against it (and would prefer this case to mapping
> > from ACPI to DT). For that case we will also require a nailed-down boot
> > protocol that allows for either DTB or ACPI (only one at a time).
> 
> UEFI already allows this, as far as I know? Even if both are passed, we can
> easily make DT take precedence over ACPI, just like DT overrides ATAGs today.

Yes, there is no problem with a platform passing both DT and ACPI.

g.

ACPI vs DT at runtime

[Grant Likely]

On Tue, 19 Nov 2013 11:30:15 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> The UEFI spec pulls in portions of ACPI. I do not know the full extent
> of the interaction between the two, but I know that they are not
> completely decoupled. As you have pointed out we are not experienced
> with ACPI or UEFI, so I don't think we can make statements that one is
> perfectly fine without the other.

Not actually. The UEFI spec does define how to pass ACPI, but it can
boot the system without any ACPI at all. Merging UEFI support should
pretty much be a non-issue.

> > > I think that trying to shoe-horn ACPI-derived information into device
> > > tree is fundamentally the wrong approach. I don't think it encourages
> > > best practices, and I don't think it's beneficial to the long term
> > > health of Linux or the ecosystem as a whole.
> >
> > There are no known best practices with ACPI. It's a complete fumbling
> > around in the dark right now. We're complaining about reviewer bandwith
> > on DT -- do we have a single reviewer for ACPI on ARM that actually
> > knows what a good solution looks like? I don't think so.
> 
> There are many people in the Linux community who have ACPI experience.
> They may not be active on the ARM side, but it's not fair to say there
> are no known best practices. I will agree that for the level of
> variation we're likely to expect we are pushing the boundaries.

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.

> > So, until there's strong evidence that ACPI is actually going to be
> > a sane solution, in other words, until someone has shipped a system
> > that uses it (with Windows) and does it successfully without being
> > a hot mess, we shouldn't litter the kernel with it.
> 
> Again, I'm not sure that we should rely on Windows as our saviour from
> insanity. A lot of the issues we are going to encounter are going to be
> in vendor-specific code (i.e. drivers), and I do not believe that is
> solved by having a single entity in charge of the general frameworks
> those are built upon.

Personally, I think the issue of ACPI support should be taken on a
patch-by-patch basis. A lot of the things that need to be done are quite
discrete and fairly well contained. If the patches don't look that way
then push back on them. For the parts that look ready, go ahead and
merge it. Push back on the ones that don't.

> > Vendors can standardise of UEFI if they want, but I would much rather
> > see them bundle DTB images with their firmware today, than rely on early
> > buggy and still-early-on-the-learning-curve ACPI bindings that we then
> > have to live with forever.
> 
> I agree that today a DTB is preferable to an ACPI implementation.
> 
> I think that mapping from ACPI => DT is less sane than building support
> for ACPI, and is not going to help us in the long term.
> 
> I think that we need to be involved in ACPI from today if we have any
> hope of having something sane in future.

+1

g.

ACPI vs DT at runtime

[Matthew Garrett]

On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote:

> Personally, I think the issue of ACPI support should be taken on a
> patch-by-patch basis. A lot of the things that need to be done are quite
> discrete and fairly well contained. If the patches don't look that way
> then push back on them. For the parts that look ready, go ahead and
> merge it. Push back on the ones that don't.

I think the most valuable thing in ACPI is the static data tables. 
Things like BERT, EINJ, HEST, MPST and the various other bits of RAS 
functionality have value in the ARM world, and being able to share the 
implementation is a benefit. But that can be implemented without 
worrying about using ACPI for device discovery or interfacing.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

ACPI vs DT at runtime

[Grant Likely]

On Thu, 21 Nov 2013 17:01:22 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote:
> 
> > Personally, I think the issue of ACPI support should be taken on a
> > patch-by-patch basis. A lot of the things that need to be done are quite
> > discrete and fairly well contained. If the patches don't look that way
> > then push back on them. For the parts that look ready, go ahead and
> > merge it. Push back on the ones that don't.
> 
> I think the most valuable thing in ACPI is the static data tables. 
> Things like BERT, EINJ, HEST, MPST and the various other bits of RAS 
> functionality have value in the ARM world, and being able to share the 
> implementation is a benefit. But that can be implemented without 
> worrying about using ACPI for device discovery or interfacing.

/complete digression.../ As far as static tables are concerned, it would
be trivial to pull those into a DT system.

g.

ACPI vs DT at runtime

[Olof Johansson]

On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote:
> On Tue, 19 Nov 2013 11:30:15 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> > The UEFI spec pulls in portions of ACPI. I do not know the full extent
> > of the interaction between the two, but I know that they are not
> > completely decoupled. As you have pointed out we are not experienced
> > with ACPI or UEFI, so I don't think we can make statements that one is
> > perfectly fine without the other.
> 
> Not actually. The UEFI spec does define how to pass ACPI, but it can
> boot the system without any ACPI at all. Merging UEFI support should
> pretty much be a non-issue.
> 
> > > > I think that trying to shoe-horn ACPI-derived information into device
> > > > tree is fundamentally the wrong approach. I don't think it encourages
> > > > best practices, and I don't think it's beneficial to the long term
> > > > health of Linux or the ecosystem as a whole.
> > >
> > > There are no known best practices with ACPI. It's a complete fumbling
> > > around in the dark right now. We're complaining about reviewer bandwith
> > > on DT -- do we have a single reviewer for ACPI on ARM that actually
> > > knows what a good solution looks like? I don't think so.
> > 
> > There are many people in the Linux community who have ACPI experience.
> > They may not be active on the ARM side, but it's not fair to say there
> > are no known best practices. I will agree that for the level of
> > variation we're likely to expect we are pushing the boundaries.
> 
> 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.

Exposing all the low-level details of the platform is very much an
embedded mindset today. Servers don't do it with DT, nor with ACPI
today. So if you're going to build a platform for servers that is
modelled after what's done successfully so far, then sticking to that
basic concept seems like an appropriate thing to do.

> > > So, until there's strong evidence that ACPI is actually going to be
> > > a sane solution, in other words, until someone has shipped a system
> > > that uses it (with Windows) and does it successfully without being
> > > a hot mess, we shouldn't litter the kernel with it.
> > 
> > Again, I'm not sure that we should rely on Windows as our saviour from
> > insanity. A lot of the issues we are going to encounter are going to be
> > in vendor-specific code (i.e. drivers), and I do not believe that is
> > solved by having a single entity in charge of the general frameworks
> > those are built upon.
> 
> Personally, I think the issue of ACPI support should be taken on a
> patch-by-patch basis. A lot of the things that need to be done are quite
> discrete and fairly well contained. If the patches don't look that way
> then push back on them. For the parts that look ready, go ahead and
> merge it. Push back on the ones that don't.

The additional abstractions that are now pushed onto us has impact for
everybody, and will cause churn on a lot of drivers. Things such as
moving to named resources, etc. While it's easy to say "let's take the
patches one by one", that also means nobody keeps an eye on the bigger
picture and whether the whole thing makes sense or not.

So, I think we need both. Of course we're going to review patches as
they're posted (the alternative doesn't make sense). But we also need
to know what the end goal is. Nobody is presenting that today, and until
we know how steep the slippery slope will get (based on what we can see
so far), we shouldn't start down it.


-Olof

ACPI vs DT at runtime

[Matthew Garrett]

On Thu, Nov 21, 2013 at 09:58:22AM -0800, 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.

ACPI is able to ignore most of this because ACPI has (traditionally) 
been aimed at well-defined platforms. ACPI 5 adds some amount of support 
for GPIOs, but beyond that there's nothing in the spec that lets you 
expose this data.

This is, obviously, a problem. The current solution is to add DT values 
to ACPI, allowing us to continue using ACPI for device discovery and 
allowing vendors to provide platform-specific ACPI methods. There's an 
argument that in that case you might as well just use DT for device 
discovery as well and skip ACPI entirely. I'm having trouble coming up 
with strong counterarguments.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

ACPI vs DT at runtime

[Arnd Bergmann]

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

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Thu, Nov 21, 2013 at 09:58:22AM -0800, 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.

This depends what you want from ACPI, and what market ACPI is being
targetted at.

If ACPI is targetted at the embedded end, then having that information is
fundamental to good power management (think about it - if you're doing
hard power management where you need to turn on a clock from IRQ context,
can you do that by running some AML code from that context?)

If ACPI is targetted at just the server end, then at the moment it's
probably not something that's required, because fine-grained power
management isn't found on such platforms.

However, that could very well change - we are in a world where we've had
the golden years of cheap energy, and energy costs are going to go one
way and one way only - so for the server market, power management to the
same extent that we see in the embedded world will eventually transition
over into that market too.

At that point, the OS is probably going to have to know these kinds of
details so it can do fine grained power management from tricky contexts...
or we'll be running native code fragments provided by the vendor to do
that...

ACPI vs DT at runtime

[Olof Johansson]

On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Nov 21, 2013 at 09:58:22AM -0800, 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.
>
> This depends what you want from ACPI, and what market ACPI is being
> targetted at.

We're talking ACPI on servers here.


-Olof

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote:
> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > This depends what you want from ACPI, and what market ACPI is being
> > targetted at.
> 
> We're talking ACPI on servers here.

Now read the rest of my email, thanks.

ACPI vs DT at runtime

[Olof Johansson]

On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote:
>> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > This depends what you want from ACPI, and what market ACPI is being
>> > targetted at.
>>
>> We're talking ACPI on servers here.
>
> Now read the rest of my email, thanks.

Yes, there are use cases for ACPI on embedded, which is what Intel is
getting into and the standard is changing accordingly. On embedded ARM
we're quite comfortable with DT for now, so it doesn't make sense to
consider ACPI there just for the sake of it, as far as I am concerned.

And, on servers, using the embedded-targeted bindings that expose all
hardware details (and leaving implementation to the kernel) seems
counter to the main target of forwards- and backwards compatibility.
That can only really be achieved by getting rid of hardware diversity
and reaching standardized hardware platforms with discoverable
devices. Keeping the complex parts of power management out of the
kernel on those platforms is going to be important too.


-Olof

ACPI vs DT at runtime

[Grant Likely]

On Thu, 21 Nov 2013 11:31:10 -0800, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote:
> >> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > This depends what you want from ACPI, and what market ACPI is being
> >> > targetted at.
> >>
> >> We're talking ACPI on servers here.
> >
> > Now read the rest of my email, thanks.
> 
> Yes, there are use cases for ACPI on embedded, which is what Intel is
> getting into and the standard is changing accordingly. On embedded ARM
> we're quite comfortable with DT for now, so it doesn't make sense to
> consider ACPI there just for the sake of it, as far as I am concerned.
> 
> And, on servers, using the embedded-targeted bindings that expose all
> hardware details (and leaving implementation to the kernel) seems
> counter to the main target of forwards- and backwards compatibility.
> That can only really be achieved by getting rid of hardware diversity
> and reaching standardized hardware platforms with discoverable
> devices. Keeping the complex parts of power management out of the
> kernel on those platforms is going to be important too.

That is something that can definitely push back on. We've got the
collision of what have we been required to do for embedded SoCs with
technology designed for systems that aren't quite as much "fun". The
ACPI team has been investigating what is needed to port existing device
drivers to use ACPI bindings, but it is resonable to say that clocks and
regulators (for example) have no business being described in the ACPI
tree.

g.

ACPI vs DT at runtime

[Mark Brown]

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.

Indeed, and at a subsystem and platform independent driver level we do
have the x86 embedded platforms working with ACPI right now so Linux is
going to need to cope with some of this regardless of what people end up
doing for ARM servers - Intel are sending me patches for ACPI support in
ASoC for example.

> Personally, I think the issue of ACPI support should be taken on a
> patch-by-patch basis. A lot of the things that need to be done are quite
> discrete and fairly well contained. If the patches don't look that way
> then push back on them. For the parts that look ready, go ahead and
> merge it. Push back on the ones that don't.

+1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131121/1285621f/attachment.sig>

ACPI vs DT at runtime

[Jason Gunthorpe]

On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:

> first-class citizen. We don't need to modify every driver and subsystem
> to support ACPI, only those necessary to support the minimal set of
> platforms using ACPI. ACPI is new in the arm space, and we can enforce
> quality standards on ACPI _now_ above what we're allowing for DT, and
> avoid future problems.

I think to replicate the kind of 'success' ACPI sees in x86-land you
really need to push back on the HW folks and limit what drivers will
be supported on ACPI systems.

ACPI should be coupled with a standard basic HW environment -
analogous to the stable APIC, PCI and HPET standards we have in
x86. (ARMv8 only?)

Other essential devices (ethernet, graphics, etc) should fit within
the PCI framework. Again, mostly like x86.

If you don't fit in that model then use DT.

If you need the kernel to control clk, pinctrl, regulator, etc then
you should be using DT.

If you need a special one-off HW driver to boot to a console then you
should be using DT ;)

DT is here, it is working, it seems viable to set a strong goal for
ACPI and shift everything else to DT:

 ACPI systems should have the broad compatability we see in x86. New
 hardware bought today should still boot a 3 year old OS.

Jason

ACPI vs DT at runtime

[Arnd Bergmann]

On Friday 15 November 2013, Jason Gunthorpe wrote:
> 
> On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote:
> 
> > first-class citizen. We don't need to modify every driver and subsystem
> > to support ACPI, only those necessary to support the minimal set of
> > platforms using ACPI. ACPI is new in the arm space, and we can enforce
> > quality standards on ACPI now above what we're allowing for DT, and
> > avoid future problems.
> 
> I think to replicate the kind of 'success' ACPI sees in x86-land you
> really need to push back on the HW folks and limit what drivers will
> be supported on ACPI systems.
> 
> ACPI should be coupled with a standard basic HW environment -
> analogous to the stable APIC, PCI and HPET standards we have in
> x86. (ARMv8 only?)

timers and interrupts are pretty much standardized in ARMv8 and in
SMP-capable ARMv7 systems now, it's really the PCI argument that
matters here. Even on Intel's embedded SoCs, the integrated 
peripherals tend to be shown to software as standalone PCI devices
that don't need to talk to another internal device to set up
DMA, clocks, pinmux etc.

> Other essential devices (ethernet, graphics, etc) should fit within
> the PCI framework. Again, mostly like x86.
> 
> If you don't fit in that model then use DT.
> 
> If you need the kernel to control clk, pinctrl, regulator, etc then
> you should be using DT.

Exactly.

	Arnd

ACPI vs DT at runtime

[Jon Masters]

Olof, thanks for starting this thread. Mark, thanks for the followup.

Comments on both inline, below. But before I reply to the specific
points, let me add that this is clearly an emotional topic for many.
There are a great many companies involved in ARMv8 on servers, and a
great many have yet to say anything in public. I am trying to strike a
balance constantly by being fair to those who have announced and those
who have yet to do so. But regardless, we have one chance here to make a
good server platform that can challenge the incumbent architectures. If
I weren't utterly convinced of that, and of the need for such standards
as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is
involved in this space, regardless of a decision to adopt ACPI now or
later, it is coming. It can be done right now, or not.

I (and others) pushed 3 years ago for the adoption of ACPI. Dong, and
others instigated the legal processes that resulted in the movement of
ACPI under UEFI Forum recently, to become a fully open standard that can
be shaped - both by the Linux community, and by others. ACPI.next will
benefit from the same development process that has shaped UEFI standards
over the past few years, and most people here can easily get involved in
shaping that standard - as they can on x86 as well now.

I am pushing for a few other things to become public that will help to
explain why ACPI is being adopted and provide a standardized description
of the ways in which it will be used/consumed.

On 11/15/2013 04:57 AM, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
>> The more I start to see early UEFI/ACPI code, the more I am certain
>> that we want none of that crap in the kernel. It's making things
>> considerably messier, while we're already very busy trying to convert
>> everything over and enable DT -- we'll be preempting that effort just
>> to add even more boilerplate everywhere and total progress will be
>> hurt.

Firstly, I would note that I don't expect DeviceTree to go away. Only on
server class systems. I expect all server class ARMv8 systems in the
Enterprise/Cloud environment to boot using UEFI and ACPI. This is
certainly the case of most future design starts already underway. These
can either be supported properly, or not, but ignoring the impending
ACPI systems isn't practical. Translation won't work reliably either.

For the record, I did suggest to Applied that the first posting of that
SATA driver not have the ACPI bits in (since we know it needs cleaning
up to use the key/value approaches already discussed, and so on), but
after chatting with Loc about it, it seemed reasonable to use the
opportunity to start a discussion - which seems to be on cue here.

<snip>

> I'm of the opinion that the only way we should support ACPI is as a
> first-class citizen.

There really isn't another way to do it in my opinion.

> We don't need to modify every driver and subsystem
> to support ACPI, only those necessary to support the minimal set of
> platforms using ACPI. ACPI is new in the arm space, and we can enforce
> quality standards on ACPI _now_ above what we're allowing for DT, and
> avoid future problems.

This is key. It's not going to be ACPI everywhere. It's going to be ACPI
on server class systems. And later, maybe some client systems. But the
big push is from the server crowd. We need to build systems that in 5-10
years time can still boot an older kernel. This can't be done without a
standardized/versioned enumeration/discovery mechanism like ACPI that
has an API enshrined in stone as far as compatibility. Device Tree is
wonderful, anyone can make a binding and use it. Or change the binding
in the next kernel release. Or...this doesn't work in the server space.
Server platforms aren't vertically welded shut like in the embedded
space, where DeviceTree has brought all kinds of benefits for those
building with a single kernel for many different targets, but has also
seen a huge amount of churn from one kernel to the next. If I counted
the number of times I've been told "just update your dtb"...then I would
be shivering in the corner a sadden wreck. You can't "just update your
dtb" on a server class system. You shouldn't.

But anyway, emotional plea aside, a very large number of ACPI systems
are coming. Yes, I've been pushing to get existing players to switch,
but that's because I know what is coming. And if you want certain other
players to appear in this space, you'll need to have ACPI for them, too.

> There may even be things which we don't have to deal with at all on ACPI
> systems as used in servers (e.g. clock management), but perhaps we will
> if people see value in those elements.
> 
>> The server guys really want UEFI for their boot protocols,
>> installation managers, etc, etc. That's fine, let them do that, but
>> that doesn't mean we need to bring the same APIs all the way into the
>> kernel.
>>
>> So, I'm strongly urging that whatever the server guys try to do, it
>> will in the end result in the ACPI data being translated into DT
>> equivalents, such that the kernel _only_ needs to handle data via DT.
> 
> I'm not sure that translating ACPI tables to dt makes any sense. If AML
> is used (even sparingly), I do not believe that we can do any sensible
> conversion to device tree. My understanding is that AML includes
> functionality for modifying ACPI tables, and I don't see how we can
> possibly support that without having to add a lot of boilerplate to all
> the code handling AML to add a device tree backend...

AML includes code that is runtime interpreted, for things like power
button emulation and the like. You can't just translate this. This comes
up every few years - it's impractical. You'll end up having to ship both
DTB and ACPI tables for a system. Which means two tables for a platform
vendor to get right. You know what will happen - only one table with be
correct. Perhaps it seems that it will be the DTB that is more correct,
and this might be true this week, but by 2016 I *guarantee* you that the
ACPI table will be the one winning.

>> Just like PowerPC scrapes the OpenFirmware client interface to build a
>> flat device tree, we should add a pre-boot stage that scrapes
>> ACPI/UEFI data and constructs an appropriate device-tree. We can still
>> bring over ACPI methods and represent those in the DT, but we should
>> _not_ have two native interfaces.
> 
> I'm not sure the two cases are comparable. The format of the FDT was
> designed to encode the data structure used by OpenFirmware, and thus the
> two map to each other pretty well. I do not believe that mapping from
> ACPI tables to an FDT blob is anywhere near as simple, and as I mention
> above I do not believe that we can just copy over the ACPI methods in
> isolation.

Indeed. OpenFirmware and DeviceTree share an ancestry. I was pushing to
create DeviceTree back in '04 or '05 when I was working on a ppc4xx
Xilinx port and I thought there was a better way than their HAL, then
noticed that ppc64's boot protocol always created a blob and kexec'd
(for same code path regardless) itself during boot. True. So I love the
concept of DeviceTree on embedded platforms without real firmware. But
it smells a lot like OpenFirmware's tables for *very good reason*.
ACPI's DSDT is the equivalent in terms of description data, but ACPI
goes way, way beyond the level of just describing platform hardware.

<snip>

> I think that trying to shoe-horn ACPI-derived information into device
> tree is fundamentally the wrong approach. I don't think it encourages
> best practices, and I don't think it's beneficial to the long term
> health of Linux or the ecosystem as a whole.

It's going to be a messy thing to even attempt. Look, I wish we had a
time machine and could have done this whole thing years ago, but I'm not
sure it would have gone differently. ACPI is something a lot of people
emotionally hate. In the Enterprise space myself and others *need* it
(along with UEFI) to have a scalable solution that doesn't result in an
onslaught of customer support calls, which a non-standards body backed
moving target of DTB will do. And besides all of the big boys are going
to be using ACPI whether it's liked much or not.

Jon.

ACPI vs DT at runtime

[Jon Masters]

On 11/18/2013 12:19 AM, Jon Masters wrote:

> It's going to be a messy thing to even attempt. Look, I wish we had a
> time machine and could have done this whole thing years ago, but I'm not
> sure it would have gone differently. ACPI is something a lot of people
> emotionally hate. In the Enterprise space myself and others *need* it
> (along with UEFI) to have a scalable solution that doesn't result in an
> onslaught of customer support calls, which a non-standards body backed
> moving target of DTB will do. And besides all of the big boys are going
> to be using ACPI whether it's liked much or not.

A while ago I mentioned producing a series of requirements that
articulates what Red Hat thinks an ARMv8 server looks like. Suffice it
to say that such requirements do in fact exist, and will be made
available in the not too distant future as part of another doc.

Jon.

ACPI vs DT at runtime

[Olof Johansson]

On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote:
> On 11/18/2013 12:19 AM, Jon Masters wrote:
> 
> > It's going to be a messy thing to even attempt. Look, I wish we had a
> > time machine and could have done this whole thing years ago, but I'm not
> > sure it would have gone differently. ACPI is something a lot of people
> > emotionally hate. In the Enterprise space myself and others *need* it
> > (along with UEFI) to have a scalable solution that doesn't result in an
> > onslaught of customer support calls, which a non-standards body backed
> > moving target of DTB will do. And besides all of the big boys are going
> > to be using ACPI whether it's liked much or not.
> 
> A while ago I mentioned producing a series of requirements that
> articulates what Red Hat thinks an ARMv8 server looks like. Suffice it
> to say that such requirements do in fact exist, and will be made
> available in the not too distant future as part of another doc.

It's nice that there's an unpublished document with a RedHat logo on it
somewhere that mandates what we, the kernel project, is going to do.

I thought both RedHat and you personally knew that we don't do things
that way in the kernel, Jon. Published or not.


-Olof

ACPI vs DT at runtime

[Jon Masters]

On 11/18/2013 02:25 PM, Olof Johansson wrote:
> On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote:
>> On 11/18/2013 12:19 AM, Jon Masters wrote:
>>
>>> It's going to be a messy thing to even attempt. Look, I wish we had a
>>> time machine and could have done this whole thing years ago, but I'm not
>>> sure it would have gone differently. ACPI is something a lot of people
>>> emotionally hate. In the Enterprise space myself and others *need* it
>>> (along with UEFI) to have a scalable solution that doesn't result in an
>>> onslaught of customer support calls, which a non-standards body backed
>>> moving target of DTB will do. And besides all of the big boys are going
>>> to be using ACPI whether it's liked much or not.
>>
>> A while ago I mentioned producing a series of requirements that
>> articulates what Red Hat thinks an ARMv8 server looks like. Suffice it
>> to say that such requirements do in fact exist, and will be made
>> available in the not too distant future as part of another doc.
> 
> It's nice that there's an unpublished document with a RedHat logo on it
> somewhere that mandates what we, the kernel project, is going to do.
> 
> I thought both RedHat and you personally knew that we don't do things
> that way in the kernel, Jon. Published or not.

Olof, I understand completely. My hands are unfortunately tied and it's
not of my making (or my employer) on this front. In the ARM space, there
are a lot of entities involved when it comes to anything at all, and you
know what the NDA situation is like. I am pushing to get a few things
out there for broader consumption.

Jon.

ACPI vs DT at runtime

[Olof Johansson]

On Mon, Nov 18, 2013 at 12:43 PM, Jon Masters <jonathan@jonmasters.org> wrote:
> On 11/18/2013 02:25 PM, Olof Johansson wrote:
>> On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote:
>>> On 11/18/2013 12:19 AM, Jon Masters wrote:
>>>
>>>> It's going to be a messy thing to even attempt. Look, I wish we had a
>>>> time machine and could have done this whole thing years ago, but I'm not
>>>> sure it would have gone differently. ACPI is something a lot of people
>>>> emotionally hate. In the Enterprise space myself and others *need* it
>>>> (along with UEFI) to have a scalable solution that doesn't result in an
>>>> onslaught of customer support calls, which a non-standards body backed
>>>> moving target of DTB will do. And besides all of the big boys are going
>>>> to be using ACPI whether it's liked much or not.
>>>
>>> A while ago I mentioned producing a series of requirements that
>>> articulates what Red Hat thinks an ARMv8 server looks like. Suffice it
>>> to say that such requirements do in fact exist, and will be made
>>> available in the not too distant future as part of another doc.
>>
>> It's nice that there's an unpublished document with a RedHat logo on it
>> somewhere that mandates what we, the kernel project, is going to do.
>>
>> I thought both RedHat and you personally knew that we don't do things
>> that way in the kernel, Jon. Published or not.
>
> Olof, I understand completely. My hands are unfortunately tied and it's
> not of my making (or my employer) on this front. In the ARM space, there
> are a lot of entities involved when it comes to anything at all, and you
> know what the NDA situation is like. I am pushing to get a few things
> out there for broader consumption.

No, I don't think you understand. Or at least, your email is not reflecting it.

It's not whether the document is public or not that is the real
problem. The real problem is the claim that you have a platforms
requirements document that is built upon unmerged features in the
upstream kernel. Unless RedHat is willing to carry that functionality
in their own kernel instead -- if so, RedHat is of course free to
mandate whatever they want to.


-Olof

ACPI vs DT at runtime

[Richard Cochran]

On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:

> If I counted
> the number of times I've been told "just update your dtb"...then I would
> be shivering in the corner a sadden wreck. You can't "just update your
> dtb" on a server class system. You shouldn't.

Ditto for embedded, really.

Thanks,
Richard

ACPI vs DT at runtime

[Stefano Stabellini]

On Mon, 18 Nov 2013, Jon Masters wrote:
> > We don't need to modify every driver and subsystem
> > to support ACPI, only those necessary to support the minimal set of
> > platforms using ACPI. ACPI is new in the arm space, and we can enforce
> > quality standards on ACPI _now_ above what we're allowing for DT, and
> > avoid future problems.
> 
> This is key. It's not going to be ACPI everywhere. It's going to be ACPI
> on server class systems. And later, maybe some client systems. But the
> big push is from the server crowd. We need to build systems that in 5-10
> years time can still boot an older kernel. This can't be done without a
> standardized/versioned enumeration/discovery mechanism like ACPI that
> has an API enshrined in stone as far as compatibility. Device Tree is
> wonderful, anyone can make a binding and use it. Or change the binding
> in the next kernel release. Or...this doesn't work in the server space.
> Server platforms aren't vertically welded shut like in the embedded
> space, where DeviceTree has brought all kinds of benefits for those
> building with a single kernel for many different targets, but has also
> seen a huge amount of churn from one kernel to the next. If I counted
> the number of times I've been told "just update your dtb"...then I would
> be shivering in the corner a sadden wreck. You can't "just update your
> dtb" on a server class system. You shouldn't.

Isn't this a matter of ensuring backward compatibility for device
tree support in the kernel? This topic has already been discussed and
agreed upon at the minisummit.

Also I think that most of the churn was due to the fact that device tree
was new in linux-arm. My guess is that something similar could easily
happen to acpi support for linux-arm too during the first couple of
years of development.


> But anyway, emotional plea aside, a very large number of ACPI systems
> are coming. Yes, I've been pushing to get existing players to switch,
> but that's because I know what is coming. And if you want certain other
> players to appear in this space, you'll need to have ACPI for them, too.

What systems? You haven't named any.
Your basic argument is: "I know things you don't know, trust me".
I don't think that is good enough.


> AML includes code that is runtime interpreted, for things like power
> button emulation and the like. You can't just translate this. This comes
> up every few years - it's impractical. You'll end up having to ship both
> DTB and ACPI tables for a system. Which means two tables for a platform
> vendor to get right. You know what will happen - only one table with be
> correct. 

No. Most likely they are going to be both wrong, except that DTB can
be fixed.
In my x86 years I have seen many broken ACPI tables that only work on
Windows, because that's the only OS they were tested with.


> Perhaps it seems that it will be the DTB that is more correct,
> and this might be true this week, but by 2016 I *guarantee* you that the
> ACPI table will be the one winning.

I would be careful making statements like that: many high profile people
risked similar predictions in the past about the success of a technology
or the other and they failed spectacularly.

ACPI vs DT at runtime

[Mark Brown]

On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:

> has an API enshrined in stone as far as compatibility. Device Tree is
> wonderful, anyone can make a binding and use it. Or change the binding
> in the next kernel release. Or...this doesn't work in the server space.

This isn't really a property of DT, it's a property of the way people
have been using the DT - people have been running with baked in DTs on
PowerPC and SPARC systems for quite some time now.  It's not obvious how
writing the data out in one format rather than another addresses this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/feb59cb5/attachment.sig>

ACPI vs DT at runtime

[Olof Johansson]

[adding back devicetree at vger.kernel.org]

On Mon, Nov 18, 2013 at 03:00:52PM +0000, Mark Brown wrote:
> On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> 
> > has an API enshrined in stone as far as compatibility. Device Tree is
> > wonderful, anyone can make a binding and use it. Or change the binding
> > in the next kernel release. Or...this doesn't work in the server space.
> 
> This isn't really a property of DT, it's a property of the way people
> have been using the DT - people have been running with baked in DTs on
> PowerPC and SPARC systems for quite some time now.  It's not obvious how
> writing the data out in one format rather than another addresses this.

+1. And we're now changing the way DT is approached in a manner that will
solve this problem.

I know people have been frustrated that they need to keep the DT in sync with
the kernel. But we've always been upfront with the requirement, and why we've
been having it. We're now changing this requirement, which should help sort out
practically all of the concerns at hand.


-Olof

ACPI vs DT at runtime

[Richard Cochran]

On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote:
> 
> I know people have been frustrated that they need to keep the DT in sync with
> the kernel. But we've always been upfront with the requirement, and why we've
> been having it. We're now changing this requirement, which should help sort out
> practically all of the concerns at hand.

Sorry, but this really gets my goat. When have you been upfront about
the unstable DT idea? Was it when you suddenly, retrospectively
announced this as a fact?

   http://thread.gmane.org/gmane.linux.kernel/1532141

I asked nicely for a pointer to some documentation of this so-called
decision,

   http://thread.gmane.org/gmane.linux.kernel/1532141

and all I could hear was the crickets. It really looks like you guys
have been making this up as you went along.

Thanks,
Richard

ACPI vs DT at runtime

[Olof Johansson]

[Adding Grant]

On Tue, Nov 19, 2013 at 10:12:17AM +0100, Richard Cochran wrote:
> On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote:
> > 
> > I know people have been frustrated that they need to keep the DT in sync with
> > the kernel. But we've always been upfront with the requirement, and why we've
> > been having it. We're now changing this requirement, which should help sort out
> > practically all of the concerns at hand.
> 
> Sorry, but this really gets my goat. When have you been upfront about
> the unstable DT idea?

As I said, from the very beginning. It's why we decided to have the DTS hosted
in the kernel tree as well. The approach has always been "we'll move it out
eventually when things settle down", but that's always been pushed off so far.

This is just a tangent and a distraction anyway: You should know by
now that we've decided to keep backwards compatibility going forward,
so any argument about why we did it differently before is leading nowhere.


-Olof

ACPI vs DT at runtime

[Richard Cochran]

On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote:
> 
> This is just a tangent and a distraction anyway: You should know by
> now that we've decided to keep backwards compatibility going forward,
> so any argument about why we did it differently before is leading nowhere.

Yes, I know it is tangent, but the tone in which you address people
(like Jon Masters) who complain about DT quality is really not fair.

When DT for arm was first proposed, I argued against it in vain.
Since then, I have really, truly tried my best to keep on top of the
DT discussions on the arm list, because everyone working on the arm
platform will have to know DT intimately, whether they want to or not.

Now, I never saw any proclamation or discussion about "DT is in flux"
on the arm list. If I had, I surely would have complained, and loudly.
AFAICT, this decision was made in rather private circles, but you talk
as if this was abundantly clear. *It was not.*

Or if it was announced in some way, just show me where. Otherwise,
please stop the "we were upfront about this from day one" excuses.

Thanks,
Richard

ACPI vs DT at runtime

[Grant Likely]

On Wed, 20 Nov 2013 07:40:57 +0100, Richard Cochran <richardcochran@gmail.com> wrote:
> On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote:
> > 
> > This is just a tangent and a distraction anyway: You should know by
> > now that we've decided to keep backwards compatibility going forward,
> > so any argument about why we did it differently before is leading nowhere.
> 
> Yes, I know it is tangent, but the tone in which you address people
> (like Jon Masters) who complain about DT quality is really not fair.
> 
> When DT for arm was first proposed, I argued against it in vain.
> Since then, I have really, truly tried my best to keep on top of the
> DT discussions on the arm list, because everyone working on the arm
> platform will have to know DT intimately, whether they want to or not.
> 
> Now, I never saw any proclamation or discussion about "DT is in flux"
> on the arm list. If I had, I surely would have complained, and loudly.
> AFAICT, this decision was made in rather private circles, but you talk
> as if this was abundantly clear. *It was not.*
> 
> Or if it was announced in some way, just show me where. Otherwise,
> please stop the "we were upfront about this from day one" excuses.

No, I cannot point at any one place where it was stated outright. My
memory is not that good. There were lots of times the stability of DT
bindings was discussed, and I certainly have told people on the mailing
list to keep their dtb updated while we are figuring out things like
clock bindings and adding functionality. I'm sorry that it wasn't more
clear. As has already been said in this thread, when the DT migration
started, we didn't know how it should all look and work. It took time to
figure out what was sane and what was not.

g.

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
> Now, I never saw any proclamation or discussion about "DT is in flux"
> on the arm list. If I had, I surely would have complained, and loudly.
> AFAICT, this decision was made in rather private circles, but you talk
> as if this was abundantly clear. *It was not.*

DT has been discussed several times over this year alone, which
included discussions about the stability of bindings.  Various
people in those threads (including myself) have put their views
forward.

My position has been that if an interface ends up being published in a
-final kernel, then it is part of the ABI, because a -final kernel is
an end-product.  It's a final release which says "we've done the
development, it's finished for users use."  If it's not then it shouldn't
be in a -final kernel, or if it has to be there for development purposes,
it needs to be hidden behind a "this is in development" label.

I've said that several times in the DT discussions and I believe
basically been ignored.  Frankly, I've said my bit and I've given up
caring.

If no one wants to listen, my attitude now is to just shut up and let
people learn their lessons the hard way.

A bit like what I ended up doing with the clk API and the idiocracy over
the "let's pass a NULL struct device and a system clock name because its
simple" stuff which then caused people a lot of pain... and guess what,
when done right (like the majority of cases today) it's a hell of a lot
easier.  People had to be left to find out for themselves that I was
right.

ACPI vs DT at runtime

[Grant Likely]

On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
> > Now, I never saw any proclamation or discussion about "DT is in flux"
> > on the arm list. If I had, I surely would have complained, and loudly.
> > AFAICT, this decision was made in rather private circles, but you talk
> > as if this was abundantly clear. *It was not.*
> 
> DT has been discussed several times over this year alone, which
> included discussions about the stability of bindings.  Various
> people in those threads (including myself) have put their views
> forward.
> 
> My position has been that if an interface ends up being published in a
> -final kernel, then it is part of the ABI, because a -final kernel is
> an end-product.  It's a final release which says "we've done the
> development, it's finished for users use."  If it's not then it shouldn't
> be in a -final kernel, or if it has to be there for development purposes,
> it needs to be hidden behind a "this is in development" label.
> 
> I've said that several times in the DT discussions and I believe
> basically been ignored.  Frankly, I've said my bit and I've given up
> caring.

Umm. Not sure why you feel ignored. We're absolutely going for stability
now.

g.

ACPI vs DT at runtime

[Catalin Marinas]

On 21 November 2013 20:47, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
>> > Now, I never saw any proclamation or discussion about "DT is in flux"
>> > on the arm list. If I had, I surely would have complained, and loudly.
>> > AFAICT, this decision was made in rather private circles, but you talk
>> > as if this was abundantly clear. *It was not.*
>>
>> DT has been discussed several times over this year alone, which
>> included discussions about the stability of bindings.  Various
>> people in those threads (including myself) have put their views
>> forward.
>>
>> My position has been that if an interface ends up being published in a
>> -final kernel, then it is part of the ABI, because a -final kernel is
>> an end-product.  It's a final release which says "we've done the
>> development, it's finished for users use."  If it's not then it shouldn't
>> be in a -final kernel, or if it has to be there for development purposes,
>> it needs to be hidden behind a "this is in development" label.

+1

>> I've said that several times in the DT discussions and I believe
>> basically been ignored.  Frankly, I've said my bit and I've given up
>> caring.
>
> Umm. Not sure why you feel ignored. We're absolutely going for stability
> now.

What I was hoping for is a better way to enforce this by taking the
dts files out of the kernel. I think that's the point where the
bindings can become ABI. In the meantime we rely on contributors and
reviewers making sure backwards compatibility is preserved. But I
guess we'll eventually get there.

-- 
Catalin

ACPI vs DT at runtime

[Pantelis Antoniou]

Hi

On Nov 22, 2013, at 12:43 PM, Catalin Marinas wrote:

> On 21 November 2013 20:47, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>>> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
>>>> Now, I never saw any proclamation or discussion about "DT is in flux"
>>>> on the arm list. If I had, I surely would have complained, and loudly.
>>>> AFAICT, this decision was made in rather private circles, but you talk
>>>> as if this was abundantly clear. *It was not.*
>>> 
>>> DT has been discussed several times over this year alone, which
>>> included discussions about the stability of bindings.  Various
>>> people in those threads (including myself) have put their views
>>> forward.
>>> 
>>> My position has been that if an interface ends up being published in a
>>> -final kernel, then it is part of the ABI, because a -final kernel is
>>> an end-product.  It's a final release which says "we've done the
>>> development, it's finished for users use."  If it's not then it shouldn't
>>> be in a -final kernel, or if it has to be there for development purposes,
>>> it needs to be hidden behind a "this is in development" label.
> 
> +1
> 
>>> I've said that several times in the DT discussions and I believe
>>> basically been ignored.  Frankly, I've said my bit and I've given up
>>> caring.
>> 
>> Umm. Not sure why you feel ignored. We're absolutely going for stability
>> now.
> 
> What I was hoping for is a better way to enforce this by taking the
> dts files out of the kernel. I think that's the point where the
> bindings can become ABI. In the meantime we rely on contributors and
> reviewers making sure backwards compatibility is preserved. But I
> guess we'll eventually get there.
> 

As one that's going to be dealing with this, please don't take the DTS
files from the kernel.

If you do this, I can guarantee that within a year almost no ARM board using DT
will boot a mainline kernel.

The reason is that vendors have enough trouble (and failing) tracking a single
tree, adding yet another will just end to the vendor trees as far as the eye can see.

Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other
customer board will work.

> -- 
> Catalin
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards

-- Pantelis

ACPI vs DT at runtime

[Alexander Holler]

Am 22.11.2013 13:00, schrieb Pantelis Antoniou:

> As one that's going to be dealing with this, please don't take the DTS
> files from the kernel.
>
> If you do this, I can guarantee that within a year almost no ARM board using DT
> will boot a mainline kernel.
>
> The reason is that vendors have enough trouble (and failing) tracking a single
> tree, adding yet another will just end to the vendor trees as far as the eye can see.
>
> Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other
> customer board will work.

A bit late (I don't follow the ML (or what happens in the ARM world) 
closely, but as I've recently read that ARM64 will go UEFI and ACPI, I 
wonder what was the reasoning behind that decision.

Does anyone really assume we will become high quality UEFI and ACPI 
blobs from vendors? And such with reasonable support/update periods?

For me that sounds like someone asked dreamers and was unable to adjust 
those answers in regard to reality.

Regards,

Alexander Holler

ACPI vs DT at runtime

[Arnd Bergmann]

On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
> 
> A bit late (I don't follow the ML (or what happens in the ARM world) 
> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I 
> wonder what was the reasoning behind that decision.
> 
> Does anyone really assume we will become high quality UEFI and ACPI 
> blobs from vendors? And such with reasonable support/update periods?
> 
> For me that sounds like someone asked dreamers and was unable to adjust 
> those answers in regard to reality.

Where did you read that? It's simply not true and we should make sure
people stop spreading dangerous misinformation.

Regarding UEFI, I don't expect that to change much for Linux, since
it has very little visibility at runtime. UEFI makes sense for some
systems, and we can support that easily. The license is a bit problematic,
since it allows shipping a system without bootloader sources, but other
boot loaders allow that as well, and a lot of companies ship pirated
u-boot without sources, too.

ACPI is a lot harder to support, as it conflicts with the normal DT
probing method, and will be visible to a lot of drivers. I expect
that we will see systems shipping with ACPI at some point, but
so far, nobody has made a serious submission for supporting that,
so it's likely a few years out, and it will only be a small subset
of the shipping systems: basically anything that tries to look like
an x86 PC server rather than an embedded system.

There is ongoing work from Linaro to provide a base enablement of
ACPI on ARM64. Those patches are looking harmless enough, but the
current plan is to not merge them until there is an actual user
who is submitting their platform specific code based on that, and
not before we have clear rules about what systems should or should
not be using ACPI. 

For all embedded systems, DT remains the way to pass data about
nondiscoverable devices on arm64, and I expect that to include
"server" machines based on embedded SoCs.

	Arnd

ACPI vs DT at runtime

[Alexander Holler]

Am 05.05.2014 16:41, schrieb Arnd Bergmann:
> On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
>>
>> A bit late (I don't follow the ML (or what happens in the ARM world)
>> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I
>> wonder what was the reasoning behind that decision.
>>
>> Does anyone really assume we will become high quality UEFI and ACPI
>> blobs from vendors? And such with reasonable support/update periods?
>>
>> For me that sounds like someone asked dreamers and was unable to adjust
>> those answers in regard to reality.
>
> Where did you read that? It's simply not true and we should make sure
> people stop spreading dangerous misinformation.

I've recently read Grant Likely's blog entry about armv8 servers: 
http://www.secretlab.ca/archives/27 (I've read the disclaimer too ;) )

> Regarding UEFI, I don't expect that to change much for Linux, since
> it has very little visibility at runtime. UEFI makes sense for some
> systems, and we can support that easily. The license is a bit problematic,
> since it allows shipping a system without bootloader sources, but other
> boot loaders allow that as well, and a lot of companies ship pirated
> u-boot without sources, too.
>
> ACPI is a lot harder to support, as it conflicts with the normal DT
> probing method, and will be visible to a lot of drivers. I expect
> that we will see systems shipping with ACPI at some point, but
> so far, nobody has made a serious submission for supporting that,
> so it's likely a few years out, and it will only be a small subset
> of the shipping systems: basically anything that tries to look like
> an x86 PC server rather than an embedded system.
>
> There is ongoing work from Linaro to provide a base enablement of
> ACPI on ARM64. Those patches are looking harmless enough, but the
> current plan is to not merge them until there is an actual user
> who is submitting their platform specific code based on that, and
> not before we have clear rules about what systems should or should
> not be using ACPI.
>
> For all embedded systems, DT remains the way to pass data about
> nondiscoverable devices on arm64, and I expect that to include
> "server" machines based on embedded SoCs.

I usually avoid to talk about embedded systems as something different 
(e.g. than servers). I think such differentations don't make much sense 
anymore in times where people are getting in need of an administrator 
for their phones. ;)

The problem I see is that if ARM requires UEFI and ACPI for general 
purpose ARMv8 servers, SOC vendors and the kernel will have to support 
that (I make the maybe silly assumption every ARMv8 SOC vendor wants to 
play in the server market). That means the kernel has to support it too.

And nobody likes to support two types of something. So there is a 
requirement (on paper) for UEFI and ACPI (both likely closed blobs), but 
none for the open stuff. And when I now start to think about paper 
loving vogons, I don't need much imagination which type will be 
streamlined away.

Regards,

Alexander Holler

ACPI vs DT at runtime

[Arnd Bergmann]

On Monday 05 May 2014 17:29:47 Alexander Holler wrote:
> Am 05.05.2014 16:41, schrieb Arnd Bergmann:
> > On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
> >>
> >> A bit late (I don't follow the ML (or what happens in the ARM world)
> >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I
> >> wonder what was the reasoning behind that decision.
> >>
> >> Does anyone really assume we will become high quality UEFI and ACPI
> >> blobs from vendors? And such with reasonable support/update periods?
> >>
> >> For me that sounds like someone asked dreamers and was unable to adjust
> >> those answers in regard to reality.
> >
> > Where did you read that? It's simply not true and we should make sure
> > people stop spreading dangerous misinformation.
> 
> I've recently read Grant Likely's blog entry about armv8 servers: 
> http://www.secretlab.ca/archives/27 (I've read the disclaimer too  )

Ok, that is fine. Everything he says there is ok, but it's easy to
miss the point that he is only talking about general-purpose servers
there.

> > For all embedded systems, DT remains the way to pass data about
> > nondiscoverable devices on arm64, and I expect that to include
> > "server" machines based on embedded SoCs.
> 
> I usually avoid to talk about embedded systems as something different 
> (e.g. than servers). I think such differentations don't make much sense 
> anymore in times where people are getting in need of an administrator 
> for their phones. 

It's the server people that see themselves as something different
though. Which is funny because they came up with the idea to use
ACPI in order to improve interoperability between hardware vendors,
and now that they actually want to come out with systems, everything
can already be interoperable, except that ACPI support is getting
in the way.

> The problem I see is that if ARM requires UEFI and ACPI for general 
> purpose ARMv8 servers, SOC vendors and the kernel will have to support 
> that (I make the maybe silly assumption every ARMv8 SOC vendor wants to 
> play in the server market). That means the kernel has to support it too.

I don't think they are in a position to make that a requirement
for servers in general. There is a boot architecture document that
requires the use of ACPI for compliant systems. That doesn't prevent
anyone from shipping a noncompliant system. I think it's similar to
the SBSA specification: It's nice for companies to build a system
compliant with that in theory, because then they get support for
any OS that supports compliant systems, but in practice, I expect
most of them to treat the spec as more of a suggestion and take
shortcuts wherever it suits them.

> And nobody likes to support two types of something. So there is a 
> requirement (on paper) for UEFI and ACPI (both likely closed blobs), but 
> none for the open stuff. And when I now start to think about paper 
> loving vogons, I don't need much imagination which type will be 
> streamlined away.

I'm very strongly supporting the idea that we should not have two
different kinds of device abstractions for a given SoC family. I also
think we have two very distinct groups of SoC vendors here:

* One side actively wants to use APCI, as they want to support MS Windows,
  and they have fast and simple general-purpose SoCs designed around
  the ACPI concepts and SBSA compliance. They wouldn't ship an open
  system anyway, and when they can show a reasonable implementation
  of ACPI that works on their systems, we will very likely merge that.

* The other side has existing special-purpose SoC designs with ARM32,
  PowerPC, MIPS or other CPU cores and they want to migrate to ARM64
  because everyone else is doing that too. They ship whatever their
  customers want, but they care little about Windows support, or strict
  standards compliance as long as their customers are happy. There is
  a lot of opposition to ACPI both in the customer base and the upstream
  Linux community for these machines, so these are likely to stay with
  DT for the foreseeable future. In fact, fear over fragmentation with
  ACPI on these systems one of the issues currently holding up merging
  ACPI for the first category.

	Arnd

ACPI vs DT at runtime

[Grant Likely]

On Mon, 05 May 2014 17:29:47 +0200, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 05.05.2014 16:41, schrieb Arnd Bergmann:
> > On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
> >>
> >> A bit late (I don't follow the ML (or what happens in the ARM world)
> >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I
> >> wonder what was the reasoning behind that decision.
> >>
> >> Does anyone really assume we will become high quality UEFI and ACPI
> >> blobs from vendors? And such with reasonable support/update periods?
> >>
> >> For me that sounds like someone asked dreamers and was unable to adjust
> >> those answers in regard to reality.
> >
> > Where did you read that? It's simply not true and we should make sure
> > people stop spreading dangerous misinformation.
> 
> I've recently read Grant Likely's blog entry about armv8 servers: 
> http://www.secretlab.ca/archives/27 (I've read the disclaimer too ;) )

The purpose of that blog post was to address the questions around ARM
server architecture requirements including ACPI and UEFI, but there is a
big gap between the requrement and what actually works now. ARM server
hardware is going to be available well before UEFI and ACPI
(especially ACPI) infrastructure has stablized. I was trying to lay a
roadmap that acknowledges the gap and provides a way for vendors to ship
hardware now that is supported by the mainline kernel.

The constraints that are driving all of this on servers simply don't
exist on embedded and mobile. There really is zero advantage to using
ACPI if the only OS that will ever run on the device is Linux.

g.

ACPI vs DT at runtime

[Grant Likely]

On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 22.11.2013 13:00, schrieb Pantelis Antoniou:
> 
> > As one that's going to be dealing with this, please don't take the DTS
> > files from the kernel.
> >
> > If you do this, I can guarantee that within a year almost no ARM board using DT
> > will boot a mainline kernel.
> >
> > The reason is that vendors have enough trouble (and failing) tracking a single
> > tree, adding yet another will just end to the vendor trees as far as the eye can see.
> >
> > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other
> > customer board will work.
> 
> A bit late (I don't follow the ML (or what happens in the ARM world) 
> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I 
> wonder what was the reasoning behind that decision.

ARM64 will include support for UEFI an ACPI, but U-Boot and DT are not
going away. Really the only market segment that will care about ACPI is
ARM servers. Nobody else (embedded, mobile) needs to worry about it.

g.

ACPI vs DT at runtime

[Olof Johansson]

On Tue, May 6, 2014 at 8:27 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler <holler@ahsoftware.de> wrote:
>> Am 22.11.2013 13:00, schrieb Pantelis Antoniou:
>>
>> > As one that's going to be dealing with this, please don't take the DTS
>> > files from the kernel.
>> >
>> > If you do this, I can guarantee that within a year almost no ARM board using DT
>> > will boot a mainline kernel.
>> >
>> > The reason is that vendors have enough trouble (and failing) tracking a single
>> > tree, adding yet another will just end to the vendor trees as far as the eye can see.
>> >
>> > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other
>> > customer board will work.
>>
>> A bit late (I don't follow the ML (or what happens in the ARM world)
>> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I
>> wonder what was the reasoning behind that decision.
>
> ARM64 will include support for UEFI an ACPI, but U-Boot and DT are not
> going away. Really the only market segment that will care about ACPI is
> ARM servers. Nobody else (embedded, mobile) needs to worry about it.

I do find it quite interesting to see what is actually launched by
vendors though. The "enterprise" chipsets have not yet shown up. Or,
rather, the only one that is out is X-Gene and it's not SBSA compliant
and thus doesn't fall into the ACPI category.

The AMD announcements yesterday clearly targets their chip to much
broader markets than just enterprise ("high density servers" was the
only market segment that overlaps somewhat with "enterprise" in their
announcements).

So, as Arnd and others have said for a while, it's definitely not a
black and white picture we're looking at. The AMD chips, in
particular, are targeted at mobile and embedded, but they share the
non-CPU part of the SoC with x86. It'd be really interesting to hear
what their plans are for software support of that, but they are so far
absent from any discussions. I really hope they can crawl out of the
woodwork and participate now that the roadmap is made public.


-Olof

ACPI vs DT at runtime

[Rob Herring]

On Sun, Nov 17, 2013 at 11:19 PM, Jon Masters <jonathan@jonmasters.org> wrote:
> Olof, thanks for starting this thread. Mark, thanks for the followup.
>
> Comments on both inline, below. But before I reply to the specific
> points, let me add that this is clearly an emotional topic for many.
> There are a great many companies involved in ARMv8 on servers, and a
> great many have yet to say anything in public. I am trying to strike a
> balance constantly by being fair to those who have announced and those
> who have yet to do so. But regardless, we have one chance here to make a
> good server platform that can challenge the incumbent architectures. If
> I weren't utterly convinced of that, and of the need for such standards
> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is
> involved in this space, regardless of a decision to adopt ACPI now or
> later, it is coming. It can be done right now, or not.
>
> I (and others) pushed 3 years ago for the adoption of ACPI. Dong, and
> others instigated the legal processes that resulted in the movement of
> ACPI under UEFI Forum recently, to become a fully open standard that can
> be shaped - both by the Linux community, and by others. ACPI.next will
> benefit from the same development process that has shaped UEFI standards
> over the past few years, and most people here can easily get involved in
> shaping that standard - as they can on x86 as well now.
>
> I am pushing for a few other things to become public that will help to
> explain why ACPI is being adopted and provide a standardized description
> of the ways in which it will be used/consumed.
>
> On 11/15/2013 04:57 AM, Mark Rutland wrote:
>> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
>>> The more I start to see early UEFI/ACPI code, the more I am certain
>>> that we want none of that crap in the kernel. It's making things
>>> considerably messier, while we're already very busy trying to convert
>>> everything over and enable DT -- we'll be preempting that effort just
>>> to add even more boilerplate everywhere and total progress will be
>>> hurt.
>
> Firstly, I would note that I don't expect DeviceTree to go away. Only on
> server class systems. I expect all server class ARMv8 systems in the
> Enterprise/Cloud environment to boot using UEFI and ACPI. This is
> certainly the case of most future design starts already underway. These
> can either be supported properly, or not, but ignoring the impending
> ACPI systems isn't practical. Translation won't work reliably either.
>
> For the record, I did suggest to Applied that the first posting of that
> SATA driver not have the ACPI bits in (since we know it needs cleaning
> up to use the key/value approaches already discussed, and so on), but
> after chatting with Loc about it, it seemed reasonable to use the
> opportunity to start a discussion - which seems to be on cue here.

That and the Exynos SATA support are great examples of how ACPI won't
help solve anything. Both are "standard AHCI" yet require lots of code
at runtime that ACPI is simply not going abstract away. Even we had to
do modifications for highbank due to an errata. What's to keep the
next gen chips from changing because they will. New process technology
will mean new phy which will no doubt have different programming or
quirks.


>> I'm of the opinion that the only way we should support ACPI is as a
>> first-class citizen.
>
> There really isn't another way to do it in my opinion.
>
>> We don't need to modify every driver and subsystem
>> to support ACPI, only those necessary to support the minimal set of
>> platforms using ACPI. ACPI is new in the arm space, and we can enforce
>> quality standards on ACPI _now_ above what we're allowing for DT, and
>> avoid future problems.
>
> This is key. It's not going to be ACPI everywhere. It's going to be ACPI
> on server class systems. And later, maybe some client systems. But the
> big push is from the server crowd. We need to build systems that in 5-10
> years time can still boot an older kernel. This can't be done without a
> standardized/versioned enumeration/discovery mechanism like ACPI that
> has an API enshrined in stone as far as compatibility. Device Tree is
> wonderful, anyone can make a binding and use it. Or change the binding
> in the next kernel release. Or...this doesn't work in the server space.
> Server platforms aren't vertically welded shut like in the embedded
> space, where DeviceTree has brought all kinds of benefits for those
> building with a single kernel for many different targets, but has also
> seen a huge amount of churn from one kernel to the next. If I counted
> the number of times I've been told "just update your dtb"...then I would
> be shivering in the corner a sadden wreck. You can't "just update your
> dtb" on a server class system. You shouldn't.

I think people are being misled that ACPI somehow solves the problem
of new systems just work. It doesn't. It is having a single platform,
tons of legacy h/w or emulation of the h/w, and the ability to trap
into the firmware. That all takes upfront design and verification
requirements to achieve. This is not how the ARM world works. Yes, we
have secret documents attempting to standardize things, but they are
hardly sufficient. Using AHCI for SATA is specified, but the above
example shows why this is insufficient. Granted, those chips were not
designed to target any standardization doc, but I doubt anyone reads
the doc and believes they are not already compliant. When it comes
down to changing the kernel or spinning the Si, vendors are going to
do the former.

> But anyway, emotional plea aside, a very large number of ACPI systems
> are coming. Yes, I've been pushing to get existing players to switch,
> but that's because I know what is coming. And if you want certain other
> players to appear in this space, you'll need to have ACPI for them, too.

Well, first a large number of DT systems are coming because ACPI is
simply not ready. Yes, some of the core ACPI support is getting in
place, but until how to deal with it in drivers is worked out drivers
are going to use DT. As this thread shows, there is currently nothing
more than ideas thrown around of how to deal with both.

>> There may even be things which we don't have to deal with at all on ACPI
>> systems as used in servers (e.g. clock management), but perhaps we will
>> if people see value in those elements.
>>
>>> The server guys really want UEFI for their boot protocols,
>>> installation managers, etc, etc. That's fine, let them do that, but
>>> that doesn't mean we need to bring the same APIs all the way into the
>>> kernel.
>>>
>>> So, I'm strongly urging that whatever the server guys try to do, it
>>> will in the end result in the ACPI data being translated into DT
>>> equivalents, such that the kernel _only_ needs to handle data via DT.
>>
>> I'm not sure that translating ACPI tables to dt makes any sense. If AML
>> is used (even sparingly), I do not believe that we can do any sensible
>> conversion to device tree. My understanding is that AML includes
>> functionality for modifying ACPI tables, and I don't see how we can
>> possibly support that without having to add a lot of boilerplate to all
>> the code handling AML to add a device tree backend...
>
> AML includes code that is runtime interpreted, for things like power
> button emulation and the like. You can't just translate this. This comes
> up every few years - it's impractical. You'll end up having to ship both
> DTB and ACPI tables for a system. Which means two tables for a platform
> vendor to get right. You know what will happen - only one table with be
> correct. Perhaps it seems that it will be the DTB that is more correct,
> and this might be true this week, but by 2016 I *guarantee* you that the
> ACPI table will be the one winning.

Perhaps we spend so much pointless effort on ACPI conversion rather
than areas that really benefit end users that we win the battle and
lose the war.

Rob

ACPI vs DT at runtime

[Olof Johansson]

Jon,

On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> Olof, thanks for starting this thread. Mark, thanks for the followup.

Your mailer is dropping all ccs to your emails, so I didn't get a copy of this
in my inbox. You might want to check the configuration at your end.

I've added back the cc recipients.

> Comments on both inline, below. But before I reply to the specific
> points, let me add that this is clearly an emotional topic for many.

I'm sorry that it's so emotional. Let's keep to technical arguments.

> There are a great many companies involved in ARMv8 on servers, and a
> great many have yet to say anything in public. I am trying to strike a
> balance constantly by being fair to those who have announced and those
> who have yet to do so. But regardless, we have one chance here to make a
> good server platform that can challenge the incumbent architectures. If
> I weren't utterly convinced of that, and of the need for such standards
> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is
> involved in this space, regardless of a decision to adopt ACPI now or
> later, it is coming. It can be done right now, or not.

And what I am saying here is that "not right now" is the right answer
for the linux kernel. For technical reasons.

> I (and others) pushed 3 years ago for the adoption of ACPI. Dong, and
> others instigated the legal processes that resulted in the movement of
> ACPI under UEFI Forum recently, to become a fully open standard that can
> be shaped - both by the Linux community, and by others. ACPI.next will
> benefit from the same development process that has shaped UEFI standards
> over the past few years, and most people here can easily get involved in
> shaping that standard - as they can on x86 as well now.
> 
> I am pushing for a few other things to become public that will help to
> explain why ACPI is being adopted and provide a standardized description
> of the ways in which it will be used/consumed.

Which in turn is DoS:ing linux development. Now we need to sign up for
a third party committee to set the direction for the kernel? Sorry,
that's not the way we do things around here.

> On 11/15/2013 04:57 AM, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> >> The more I start to see early UEFI/ACPI code, the more I am certain
> >> that we want none of that crap in the kernel. It's making things
> >> considerably messier, while we're already very busy trying to convert
> >> everything over and enable DT -- we'll be preempting that effort just
> >> to add even more boilerplate everywhere and total progress will be
> >> hurt.
> 
> Firstly, I would note that I don't expect DeviceTree to go away. Only on
> server class systems.  I expect all server class ARMv8 systems in the
> Enterprise/Cloud environment to boot using UEFI and ACPI. This is
> certainly the case of most future design starts already underway. These
> can either be supported properly, or not, but ignoring the impending
> ACPI systems isn't practical.

Trust me, we're not going to ignore them, we want them supported.

> Translation won't work reliably either.

Nothing is going to work reliably with ACPI right now, period. It's a
completely immature technology on ARM, and if we lock in hard to the
current implementaitons we're all going to lose. Big. You have yet to
address that part of the argument in any of your replies.

It's taken us years to sort out device tree, and we've been able to cope
with it by the fact that we have been able to change both sides of the
border (both the DTB and the kernel). With ACPI, we're entering a hard
lock-in on day one.  Meanwhile the very first patches look considerably
worse than any of the first device-tree ones did, and vendors are clearly
not getting help from you.

> For the record, I did suggest to Applied that the first posting of that
> SATA driver not have the ACPI bits in (since we know it needs cleaning
> up to use the key/value approaches already discussed, and so on), but
> after chatting with Loc about it, it seemed reasonable to use the
> opportunity to start a discussion - which seems to be on cue here.

Nice.

> > I'm of the opinion that the only way we should support ACPI is as a
> > first-class citizen.
> 
> There really isn't another way to do it in my opinion.

There is. Apple, IBM and Sun obviously figured out how to ship enterprise
systems without ACPI, didn't they?

> > We don't need to modify every driver and subsystem
> > to support ACPI, only those necessary to support the minimal set of
> > platforms using ACPI. ACPI is new in the arm space, and we can enforce
> > quality standards on ACPI _now_ above what we're allowing for DT, and
> > avoid future problems.
> 
> This is key. It's not going to be ACPI everywhere. It's going to be ACPI
> on server class systems. And later, maybe some client systems. But the
> big push is from the server crowd.

Market segment is irrellevant to the discussion at hand.

> We need to build systems that in 5-10
> years time can still boot an older kernel. This can't be done without a
> standardized/versioned enumeration/discovery mechanism like ACPI that
> has an API enshrined in stone as far as compatibility. Device Tree is
> wonderful, anyone can make a binding and use it. Or change the binding
> in the next kernel release.

Clearly you haven't been following any of the recent development w.r.t. device
tree and the policy changes on backwards compatibility.

What makes you so sure that vendors won't do crazy custom stuff on
top of ACPI? You seem confident that they'll be able to sort it out
themselves. Initial data on the subject indicates the polar opposite.

> Or...this doesn't work in the server space.
> Server platforms aren't vertically welded shut like in the embedded
> space, where DeviceTree has brought all kinds of benefits for those
> building with a single kernel for many different targets, but has also
> seen a huge amount of churn from one kernel to the next. If I counted
> the number of times I've been told "just update your dtb"...then I would
> be shivering in the corner a sadden wreck. You can't "just update your
> dtb" on a server class system. You shouldn't.

You know why you've been asked to update the device trees? Because
everyone is trying to figure out how to make this all work in a good way.

With ACPI, there's _no way_ to do any of that. And you think that's a
good thing? It's not, because the alternative is to start littering the
kernel with lots and lots of quirks and fixups.

> But anyway, emotional plea aside, a very large number of ACPI systems
> are coming. Yes, I've been pushing to get existing players to switch,
> but that's because I know what is coming. And if you want certain other
> players to appear in this space, you'll need to have ACPI for them, too.

I think what concerns me the most about the current situation is
exactly this.  You've been scheming for several years now, and now
when push comes to shove, it's obvious that the vendors have no idea
what they're doing with ACPI. Whenever there's a discussion about it,
we get thrown these kind of vague "oh you'll see what's coming" arguments.

Sure, we will, but until we see these promised awesome things in public,
we're going to base things on what we know and see. And what we've
seen so far is not promising. It's looking like in the short to medium
term, locking ourselves to ACPI, on any platforms, is going to be a
huge mistake.

ACPI long-term might be a great thing, once vendors have gone through a
couple of product generations and everybody has learned how to use ACPI
properly. Until then we're building up a huge technical debt that we'll
have to carry forever.

Implement ACPI if you want, but while all those things are sorted out,
we'll continue shipping device tree. If you look at the Calxeda DT sources,
they've been completely table for quite a while now. It can, and will, be done.

> > There may even be things which we don't have to deal with at all on ACPI
> > systems as used in servers (e.g. clock management), but perhaps we will
> > if people see value in those elements.
> > 
> >> The server guys really want UEFI for their boot protocols,
> >> installation managers, etc, etc. That's fine, let them do that, but
> >> that doesn't mean we need to bring the same APIs all the way into the
> >> kernel.
> >>
> >> So, I'm strongly urging that whatever the server guys try to do, it
> >> will in the end result in the ACPI data being translated into DT
> >> equivalents, such that the kernel _only_ needs to handle data via DT.
> > 
> > I'm not sure that translating ACPI tables to dt makes any sense. If AML
> > is used (even sparingly), I do not believe that we can do any sensible
> > conversion to device tree. My understanding is that AML includes
> > functionality for modifying ACPI tables, and I don't see how we can
> > possibly support that without having to add a lot of boilerplate to all
> > the code handling AML to add a device tree backend...
> 
> AML includes code that is runtime interpreted, for things like power
> button emulation and the like. You can't just translate this. This comes
> up every few years - it's impractical. You'll end up having to ship both
> DTB and ACPI tables for a system. Which means two tables for a platform
> vendor to get right. 

Nobody is talking about removing the AML pieces here. Keep them around, but
bring them over to the DT implementation if you have to.

> You know what will happen - only one table with be
> correct. Perhaps it seems that it will be the DTB that is more correct,
> and this might be true this week, but by 2016 I *guarantee* you that the
> ACPI table will be the one winning.

Actually, that's an excellent approach to the problem at hand and pretty
the ideal outcome as far as I am concerned. Focus on DT now, enable
ACPI as much as possible but it won't be right yet so don't rely on
it. In a few years, when ACPI looks like it's sorted out and reliable,
we can switch over to it.

> > I think that trying to shoe-horn ACPI-derived information into device
> > tree is fundamentally the wrong approach. I don't think it encourages
> > best practices, and I don't think it's beneficial to the long term
> > health of Linux or the ecosystem as a whole.
> 
> It's going to be a messy thing to even attempt. Look, I wish we had a
> time machine and could have done this whole thing years ago, but I'm not
> sure it would have gone differently. ACPI is something a lot of people
> emotionally hate.

Again, I am not approaching this emotionally.

I'm looking at the quality of the initial submissions (very poor and
confused), the readiness of the kernel in general (none so far),
the way the involved parties are doing development (away from the
community and in their own little world). I also look at some of the
bottlenecks we've had with device tree (reviewer bandwidth, slow-moving
consensus/standards-driven approval process) and how it compares to the
ACPI counterparts (standards forum).

The conclusion is that we're about to embark onto something that isn't
going to be done right in the short to medium term. It just isn't. The
sooner we own up to that, the sooner we can course-correct and get back
to something that's likely to work.

The alternative is signing onto a setup that _will_ stumble right out
of the door, which in turn will mean that the high-end ARM play will be
off to a rough start instead of running as smoothly as possible.

> In the Enterprise space myself and others *need* it
> (along with UEFI) to have a scalable solution that doesn't result in an
> onslaught of customer support calls, which a non-standards body backed
> moving target of DTB will do. And besides all of the big boys are going
> to be using ACPI whether it's liked much or not.

I'm glad you've found your home with the big boys. Meanwhile, us low-lifes
working on the kernel have a job to do, which is to make sure the lower parts
of the stack will be successful on these new environments long-term,
which might have short-term difficult trade-offs. ACPI is not realistic
today, for all the reasons explained above.


-Olof

ACPI vs DT at runtime

[Jon Masters]

Hi Olof,

On 11/18/2013 02:09 PM, Olof Johansson wrote:
> Jon,
> 
> On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
>> Olof, thanks for starting this thread. Mark, thanks for the followup.
> 
> Your mailer is dropping all ccs to your emails, so I didn't get a copy of this
> in my inbox. You might want to check the configuration at your end.

I need to shoot Thunderbird for all kinds of reasons unrelated to this.
I actually am having to alternate with another laptop right now to do
email because this Thunderbird build I am running is just so sluggish
and nasty (and the other laptop setup is what is broken). But anyway,
that's something I need to fix, thanks for fixing the CCs.

> I've added back the cc recipients.
> 
>> Comments on both inline, below. But before I reply to the specific
>> points, let me add that this is clearly an emotional topic for many.
> 
> I'm sorry that it's so emotional. Let's keep to technical arguments.

I agree with you. I got worried on Friday when I saw a discussion
effectively leading with (what I read as) "let's ban all ACPI", which
really got me concerned. But then again, I've been in bed most of the
weekend sick, so I probably miss-read your intention. I apologize.

>> There are a great many companies involved in ARMv8 on servers, and a
>> great many have yet to say anything in public. I am trying to strike a
>> balance constantly by being fair to those who have announced and those
>> who have yet to do so. But regardless, we have one chance here to make a
>> good server platform that can challenge the incumbent architectures. If
>> I weren't utterly convinced of that, and of the need for such standards
>> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is
>> involved in this space, regardless of a decision to adopt ACPI now or
>> later, it is coming. It can be done right now, or not.
> 
> And what I am saying here is that "not right now" is the right answer
> for the linux kernel. For technical reasons.

I believe we can skip a lot of other conversation if I can summarize
something from this thread. Is it the case that you believe there is
room for both codepaths to exist in the upstream kernel, and for ACPI to
mature over time as it becomes "more ready"?

If the above is the case, then I don't think we disagree at all! I don't
want to kill DeviceTree, I just know (or think I do) that ACPI is going
to be the dominant force on v8 server systems. It worries me if there's
no way to let ACPI code be merged upstream until it's completely figured
out. I hope I am reading the rest of the thread correctly and understand
instead that you're saying there can be a path for both, and perhaps
those of us who require ACPI can simply state that up front and work
with partners to ensure support for those ACPI platforms is available -
and binding fixes to the standard made - while those same server
platforms might also be supported by a DeviceTree at the same time for a
period of whatever transition is required. That seems totally
acceptable. I don't see any reason why the same binary kernel image
can't boot with either a DTB or an ACPI table and indeed that would be
my preference. Some of us can require it be ACPI by policy, but others
can build kernels that use DTB on v8 servers if that's what they need
while the whole thing shakes itself out.

>> In the Enterprise space myself and others *need* it
>> (along with UEFI) to have a scalable solution that doesn't result in an
>> onslaught of customer support calls, which a non-standards body backed
>> moving target of DTB will do. And besides all of the big boys are going
>> to be using ACPI whether it's liked much or not.
> 
> I'm glad you've found your home with the big boys. Meanwhile, us low-lifes
> working on the kernel have a job to do, which is to make sure the lower parts
> of the stack will be successful on these new environments long-term,
> which might have short-term difficult trade-offs. ACPI is not realistic
> today, for all the reasons explained above.

Gah. I didn't mean to come across as offensive. Just worried. I'm in an
uncomfortable position that there are limits on what I can share about
what people are doing. I don't like or enjoy this one bit. I am pushing
for various things to change. I know it sounds like I'm sitting in a big
room with a Dr. Evil style conference table going on, but that's not the
reality. I *really* truly want ARM servers to be successful in the
marketplace and I know it will only happen (longer term) with ACPI. But
I agree the ACPI story is very much a work in progress right now. I just
want to know that there can be an upstream dual/stack ACPI story while
this is figured out - waiting years for that is going to be very
unfortunate to the overall cause. I wouldn't sound so passionate about
this if I weren't totally convinced of this reality.

Jon.

ACPI vs DT at runtime

[Olof Johansson]

Hi,

On Mon, Nov 18, 2013 at 03:54:56PM -0500, Jon Masters wrote:
> Hi Olof,
> 
> On 11/18/2013 02:09 PM, Olof Johansson wrote:
> > Jon,
> > 
> > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> >> Olof, thanks for starting this thread. Mark, thanks for the followup.
> > 
> > Your mailer is dropping all ccs to your emails, so I didn't get a copy of this
> > in my inbox. You might want to check the configuration at your end.
> 
> I need to shoot Thunderbird for all kinds of reasons unrelated to this.
> I actually am having to alternate with another laptop right now to do
> email because this Thunderbird build I am running is just so sluggish
> and nasty (and the other laptop setup is what is broken). But anyway,
> that's something I need to fix, thanks for fixing the CCs.
> 
> > I've added back the cc recipients.
> > 
> >> Comments on both inline, below. But before I reply to the specific
> >> points, let me add that this is clearly an emotional topic for many.
> > 
> > I'm sorry that it's so emotional. Let's keep to technical arguments.
> 
> I agree with you. I got worried on Friday when I saw a discussion
> effectively leading with (what I read as) "let's ban all ACPI", which
> really got me concerned. But then again, I've been in bed most of the
> weekend sick, so I probably miss-read your intention. I apologize.

My stance is the same as last week: ACPI is the wrong tool for the job
at this time on ARM. The job in question is kernel and device runtime
configuration.

In the future, it might be more suitable, but likely not for at least
a couple of years, maybe more. Making strict statements about its use in
the future seems counterproductive at this time since there's no guarantee
that it'll reach that point in a given timeframe. Maybe it will for some
firmware vendors and platform vendors, while for others it won't, etc.

> >> There are a great many companies involved in ARMv8 on servers, and a
> >> great many have yet to say anything in public. I am trying to strike a
> >> balance constantly by being fair to those who have announced and those
> >> who have yet to do so. But regardless, we have one chance here to make a
> >> good server platform that can challenge the incumbent architectures. If
> >> I weren't utterly convinced of that, and of the need for such standards
> >> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is
> >> involved in this space, regardless of a decision to adopt ACPI now or
> >> later, it is coming. It can be done right now, or not.
> > 
> > And what I am saying here is that "not right now" is the right answer
> > for the linux kernel. For technical reasons.
> 
> I believe we can skip a lot of other conversation if I can summarize
> something from this thread. Is it the case that you believe there is
> room for both codepaths to exist in the upstream kernel, and for ACPI to
> mature over time as it becomes "more ready"?

As my original email said, I don't think there's a reason to pick up
and pollute the whole kernel with double code paths at this time, while
the vendors using ACPI is still trying to figure out what to do and how
to do it. It's better to keep it out of the kernel, especially since it
will require either re-abstracting all drivers and subsystems, or adding
dual code paths to them for platform support that is likely to change.

Until then, if someone wants to boot with ACPI, then the best path would
be to translate as much of the simple data over to device tree and boot
with that as the in-kernel abstraction layer. That can be done at boot
or by crafting static device trees. Likely the first few generations of
hardware will not have elaborate complex AML-based ACPI workarounds for
stuff in the first place, so chances are this will not be a big issue.

If, down the road, ACPI seems to have their act together, have worked out
their kinks and reached a usable stable platform, then we can consider
bringing in the parts of it that doesn't make the kernel explode in
complexity and messiness. When this will be is impossible to predict
today, but I expect it to take a couple of years and some generations
of hardware.

> If the above is the case, then I don't think we disagree at all! I don't
> want to kill DeviceTree, I just know (or think I do) that ACPI is going
> to be the dominant force on v8 server systems. It worries me if there's
> no way to let ACPI code be merged upstream until it's completely figured
> out. I hope I am reading the rest of the thread correctly and understand
> instead that you're saying there can be a path for both, and perhaps
> those of us who require ACPI can simply state that up front and work
> with partners to ensure support for those ACPI platforms is available -
> and binding fixes to the standard made - while those same server
> platforms might also be supported by a DeviceTree at the same time for a
> period of whatever transition is required. That seems totally
> acceptable. I don't see any reason why the same binary kernel image
> can't boot with either a DTB or an ACPI table and indeed that would be
> my preference. Some of us can require it be ACPI by policy, but others
> can build kernels that use DTB on v8 servers if that's what they need
> while the whole thing shakes itself out.

Again, merging a substantial amount of ACPI enablement is premature for
the reasons already stated in the thread; it adds complexity and is likely
to churn several times as vendors figure out just how to work with it. The
two examples at hand (APM SATA and Exynos AHCI) both indicate that.

While vendors are free to implement it in their firmware, we are much
better off not relying on it right now. ACPI was messy on x86 in the
beginning too. Luckily we have an alternative that will get the work
done while the rest is being worked out.

So, if we're not going to merge the ACPI-enabling code yet,
mandating ACPI for booting isn't going to work if you expect to rely
on native-all-the-way-through-the-kernel ACPI implementation. It will
however work to some extent for the ACPI-to-DT approach, given that
the platforms are kept reasonably simplistic. And if it doesn't, we can
fall back to static DT and native implementation of whatever stuff ACPI
would have abstracted for us (clock drivers, reset drivers) if we really
have to.


-Olof

ACPI vs DT at runtime

[Grant Likely]

On Mon, 18 Nov 2013 11:09:29 -0800, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> 
> I'm looking at the quality of the initial submissions (very poor and
> confused), the readiness of the kernel in general (none so far),
> the way the involved parties are doing development (away from the
> community and in their own little world). I also look at some of the
> bottlenecks we've had with device tree (reviewer bandwidth, slow-moving
> consensus/standards-driven approval process) and how it compares to the
> ACPI counterparts (standards forum).
> 
> The conclusion is that we're about to embark onto something that isn't
> going to be done right in the short to medium term. It just isn't. The
> sooner we own up to that, the sooner we can course-correct and get back
> to something that's likely to work.
> 
> The alternative is signing onto a setup that _will_ stumble right out
> of the door, which in turn will mean that the high-end ARM play will be
> off to a rough start instead of running as smoothly as possible.

I completely agree here. The DT conversion was hard and it took a lot of
years. There was a lot of getting the code into shape and a lot of
people trying to get their heads around it. ACPI is exactly the same
problem. We don't know what we're doing and we don't know how to do it
yet.

I fully support getting ACPI up on ARM and the current work is good.
However, it cannot short-circuit the kernel development process.
Absolutely, push back hard on the ACPI and UEFI patches where the code
is not ready.

g.

ACPI vs DT at runtime

[David Goodenough]

On Monday 18 Nov 2013, Grant Likely wrote:
> On Mon, 18 Nov 2013 11:09:29 -0800, Olof Johansson <olof@lixom.net> wrote:
> > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> > 
> > I'm looking at the quality of the initial submissions (very poor and
> > confused), the readiness of the kernel in general (none so far),
> > the way the involved parties are doing development (away from the
> > community and in their own little world). I also look at some of the
> > bottlenecks we've had with device tree (reviewer bandwidth, slow-moving
> > consensus/standards-driven approval process) and how it compares to the
> > ACPI counterparts (standards forum).
> > 
> > The conclusion is that we're about to embark onto something that isn't
> > going to be done right in the short to medium term. It just isn't. The
> > sooner we own up to that, the sooner we can course-correct and get back
> > to something that's likely to work.
> > 
> > The alternative is signing onto a setup that _will_ stumble right out
> > of the door, which in turn will mean that the high-end ARM play will be
> > off to a rough start instead of running as smoothly as possible.
> 
> I completely agree here. The DT conversion was hard and it took a lot of
> years. There was a lot of getting the code into shape and a lot of
> people trying to get their heads around it. ACPI is exactly the same
> problem. We don't know what we're doing and we don't know how to do it
> yet.
> 
> I fully support getting ACPI up on ARM and the current work is good.
> However, it cannot short-circuit the kernel development process.
> Absolutely, push back hard on the ACPI and UEFI patches where the code
> is not ready.
> 
> g.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Would it not be possible to have ACPI read the hardware configuration
from the DT, and provide whatever services it wants, while also allowing
the kernel to retain the DT for its hardware config?  I suppose the only
thing that would be needed would be some way to mark paricular bits of
hardware (I am largely thinking of the things lmsensors deals with) as
being used by ACPI and being off limits to the kernel.

David

ACPI vs DT at runtime

[Arnd Bergmann]

On Monday 18 November 2013, David Goodenough wrote:
> Would it not be possible to have ACPI read the hardware configuration
> from the DT, and provide whatever services it wants, while also allowing
> the kernel to retain the DT for its hardware config?  I suppose the only
> thing that would be needed would be some way to mark paricular bits of
> hardware (I am largely thinking of the things lmsensors deals with) as
> being used by ACPI and being off limits to the kernel.

While that may be possible, I don't see what problem that solves. Nobody
has so far explained what problem they want to solve by using ACPI. The
only reason we are discussing this is Jon's statement that "everybody
will use it". For any specific thing you might want to do in ACPI while
leaving the rest in DT, I suspect there is an easier solution in using
just DT.

Since you seem to have something specific in mind, can you elaborate on
why you think lmsensors (or any other device you can think of) would
benefit from ACPI?

	Arnd

ACPI vs DT at runtime

[David Goodenough]

On Tuesday 19 Nov 2013, Arnd Bergmann wrote:
> On Monday 18 November 2013, David Goodenough wrote:
> > Would it not be possible to have ACPI read the hardware configuration
> > from the DT, and provide whatever services it wants, while also allowing
> > the kernel to retain the DT for its hardware config?  I suppose the only
> > thing that would be needed would be some way to mark paricular bits of
> > hardware (I am largely thinking of the things lmsensors deals with) as
> > being used by ACPI and being off limits to the kernel.
> 
> While that may be possible, I don't see what problem that solves. Nobody
> has so far explained what problem they want to solve by using ACPI. The
> only reason we are discussing this is Jon's statement that "everybody
> will use it". For any specific thing you might want to do in ACPI while
> leaving the rest in DT, I suspect there is an easier solution in using
> just DT.
It strikes me that ACPI is really two things, a provider of configuration
information and a provider of power management services.  The first of
these is - on ARM - more or less duplicated by DT, and so rather than having 
to go through the excercise of modifying the kernel to support both sources
of configuration information, I am suggesting making not just the kernel
and uboot (or whatever boot loader) use DT, but also ACPI.  So the ACPI
module for an ARM box would not have separate config information coded
into it, but rather would either read the DT from the same place as
the bootloader/kernel, or act as the source of the DT for the bootloader
/kernel.  This way the kernel does not have to be modified again, and
can simply use DT whether ACPI is present or not.
> 
> Since you seem to have something specific in mind, can you elaborate on
> why you think lmsensors (or any other device you can think of) would
> benefit from ACPI?
Its the other way around.  lmsensors often fights with ACPI in the x86
world for control of sensors and fans, and on x86 motherboards they do
silly tricks like hiding I2C busses from the kernel so that ACPI can
have sole control.  Thus lmsensors (which on x86 boxes could use a source
of information like DT as busses like I2C provide no chip ID services) needs 
to know which sensor chips are being used or controlled by ACPI so that it 
does not interfere.

David
> 
> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

ACPI vs DT at runtime

[Arnd Bergmann]

On Tuesday 19 November 2013, David Goodenough wrote:
> On Tuesday 19 Nov 2013, Arnd Bergmann wrote:
> > On Monday 18 November 2013, David Goodenough wrote:
> > > Would it not be possible to have ACPI read the hardware configuration
> > > from the DT, and provide whatever services it wants, while also allowing
> > > the kernel to retain the DT for its hardware config?  I suppose the only
> > > thing that would be needed would be some way to mark paricular bits of
> > > hardware (I am largely thinking of the things lmsensors deals with) as
> > > being used by ACPI and being off limits to the kernel.
> > 
> > While that may be possible, I don't see what problem that solves. Nobody
> > has so far explained what problem they want to solve by using ACPI. The
> > only reason we are discussing this is Jon's statement that "everybody
> > will use it". For any specific thing you might want to do in ACPI while
> > leaving the rest in DT, I suspect there is an easier solution in using
> > just DT.
>
> It strikes me that ACPI is really two things, a provider of configuration
> information and a provider of power management services.

As the acronym says, yes ;-)

> The first of
> these is - on ARM - more or less duplicated by DT, and so rather than having 
> to go through the excercise of modifying the kernel to support both sources
> of configuration information, I am suggesting making not just the kernel
> and uboot (or whatever boot loader) use DT, but also ACPI.  So the ACPI
> module for an ARM box would not have separate config information coded
> into it, but rather would either read the DT from the same place as
> the bootloader/kernel, or act as the source of the DT for the bootloader
> /kernel.  This way the kernel does not have to be modified again, and
> can simply use DT whether ACPI is present or not.

Well, this is what Olof suggested, and it may or may not be possible,
depending on what kind of data people actually want to put into ACPI
here.

> > Since you seem to have something specific in mind, can you elaborate on
> > why you think lmsensors (or any other device you can think of) would
> > benefit from ACPI?
> Its the other way around.  lmsensors often fights with ACPI in the x86
> world for control of sensors and fans, and on x86 motherboards they do
> silly tricks like hiding I2C busses from the kernel so that ACPI can
> have sole control.  Thus lmsensors (which on x86 boxes could use a source
> of information like DT as busses like I2C provide no chip ID services) needs 
> to know which sensor chips are being used or controlled by ACPI so that it 
> does not interfere.

Ah, I see. I suppose on a server, those sensors are part of the BMC anyway
and are accessible through IPMI only, so I'd hope that wouldn't be an issue.

	Arnd

ACPI vs DT at runtime

[Grant Likely]

On Mon, 18 Nov 2013 22:47:03 +0000, David Goodenough <david.goodenough@btconnect.com> wrote:
> On Monday 18 Nov 2013, Grant Likely wrote:
> > I fully support getting ACPI up on ARM and the current work is good.
> > However, it cannot short-circuit the kernel development process.
> > Absolutely, push back hard on the ACPI and UEFI patches where the code
> > is not ready.
> 
> Would it not be possible to have ACPI read the hardware configuration
> from the DT, and provide whatever services it wants, while also allowing
> the kernel to retain the DT for its hardware config?  I suppose the only
> thing that would be needed would be some way to mark paricular bits of
> hardware (I am largely thinking of the things lmsensors deals with) as
> being used by ACPI and being off limits to the kernel.

I don't think there's a lot of interesting work there. It is more
interesting to me to boot DT-only for production, but be able to use
those same systems to develop and mature the ACPI support as quickly as
possible. That is essentially what is being done right now by the Linaro
ACPI team on the Versatile Express.

g.

ACPI vs DT at runtime

[Grant Likely]

On Mon, 18 Nov 2013 00:19:18 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> > I think that trying to shoe-horn ACPI-derived information into device
> > tree is fundamentally the wrong approach. I don't think it encourages
> > best practices, and I don't think it's beneficial to the long term
> > health of Linux or the ecosystem as a whole.
> 
> It's going to be a messy thing to even attempt. Look, I wish we had a
> time machine and could have done this whole thing years ago, but I'm not
> sure it would have gone differently. ACPI is something a lot of people
> emotionally hate. In the Enterprise space myself and others *need* it
> (along with UEFI) to have a scalable solution that doesn't result in an
> onslaught of customer support calls, which a non-standards body backed
> moving target of DTB will do.

I think that sells our entire community short. The Linux kernel itself is
nowhere near standards body backed, and the userspace ABI is absolutely
stable. It's stable because we've made stability a priority. Linus and
others have been vocal about it, and maintainers have enforced it.
Suggesting the lack of a standards body means we're left with a moving
target is clearly not true.

As much as we hoped ARM ACPI support would be complete by now and merged
into the kernel, it isn't. I really can't fault (or expect) any hardware
vendor to ship only ACPI when support for it isn't in mainline.

As for DT, we discussed DT stability at length in Edinburgh. We've made
the commitment to support shipped hardware. If hardware ships with a DT
that boots on mainline, then we will not break it.

> And besides all of the big boys are going
> to be using ACPI whether it's liked much or not.

I have to call that statement out as over the line. It comes across as
attempting to shame maintainers into accepting ACPI, and further implies
that non-ACPI users are not "big boys" and therefore just playing
around. That is not okay.

The ACPI support patches must satisfy maintainers before they will be
accepted. This is normal and we've done this before. The current patches
raise serious concerns, but they're also generating constructive
feedback. If ACPI isn't there in time then we can support the hardware
with DT, whether it is provided by the firmware (preferred), or shipped
with the kernel.

g.

ACPI vs DT at runtime

[Grant Likely]

On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> > The more I start to see early UEFI/ACPI code, the more I am certain
> > that we want none of that crap in the kernel. It's making things
> > considerably messier, while we're already very busy trying to convert
> > everything over and enable DT -- we'll be preempting that effort just
> > to add even more boilerplate everywhere and total progress will be
> > hurt.
> 
> We are certainly under a lot of pressure with the device tree migration,
> and I agree that adding another information source is going to be a
> source of pain. However, I'd argue that we're going to encounter pain
> regardless of which approach we take.
> 
> I'm of the opinion that the only way we should support ACPI is as a
> first-class citizen. We don't need to modify every driver and subsystem
> to support ACPI, only those necessary to support the minimal set of
> platforms using ACPI. ACPI is new in the arm space, and we can enforce
> quality standards on ACPI _now_ above what we're allowing for DT, and
> avoid future problems.

Translated ACPI tables really don't make any sense at all. While the
models are similar in some regards, they are very different in others
and any translator (I suspect) would become very complicated to deal
with all the edge cases.

> I'm not sure that translating ACPI tables to dt makes any sense. If AML
> is used (even sparingly), I do not believe that we can do any sensible
> conversion to device tree. My understanding is that AML includes
> functionality for modifying ACPI tables, and I don't see how we can
> possibly support that without having to add a lot of boilerplate to all
> the code handling AML to add a device tree backend...

The dynamic features of AML would be a no-go. Basically, an AML method
can cause SSDT blocks to be loaded/unloaded at runtime. It doesn't edit
the tree provided at runtime, but it does augment it.

g.

ACPI vs DT at runtime

[Stefano Stabellini]

On Wed, 20 Nov 2013, Grant Likely wrote:
> On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
> > > The more I start to see early UEFI/ACPI code, the more I am certain
> > > that we want none of that crap in the kernel. It's making things
> > > considerably messier, while we're already very busy trying to convert
> > > everything over and enable DT -- we'll be preempting that effort just
> > > to add even more boilerplate everywhere and total progress will be
> > > hurt.
> > 
> > We are certainly under a lot of pressure with the device tree migration,
> > and I agree that adding another information source is going to be a
> > source of pain. However, I'd argue that we're going to encounter pain
> > regardless of which approach we take.
> > 
> > I'm of the opinion that the only way we should support ACPI is as a
> > first-class citizen. We don't need to modify every driver and subsystem
> > to support ACPI, only those necessary to support the minimal set of
> > platforms using ACPI. ACPI is new in the arm space, and we can enforce
> > quality standards on ACPI _now_ above what we're allowing for DT, and
> > avoid future problems.
> 
> Translated ACPI tables really don't make any sense at all. While the
> models are similar in some regards, they are very different in others
> and any translator (I suspect) would become very complicated to deal
> with all the edge cases.
 
If it turns out that we can't translate the ACPI tables dynamically, we
could maintain a repository of "manually" translated DTSes for all the
systems that do not ship with device tree.  Given that DTBs are fairly
small, we could stick them all in an initrd or another binary loaded by
the bootloader so that Linux and/or Xen can select the right one at boot
time.

ACPI vs DT at runtime

[Olof Johansson]

On Wed, Nov 20, 2013 at 9:43 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 20 Nov 2013, Grant Likely wrote:
>> On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote:
>> > > The more I start to see early UEFI/ACPI code, the more I am certain
>> > > that we want none of that crap in the kernel. It's making things
>> > > considerably messier, while we're already very busy trying to convert
>> > > everything over and enable DT -- we'll be preempting that effort just
>> > > to add even more boilerplate everywhere and total progress will be
>> > > hurt.
>> >
>> > We are certainly under a lot of pressure with the device tree migration,
>> > and I agree that adding another information source is going to be a
>> > source of pain. However, I'd argue that we're going to encounter pain
>> > regardless of which approach we take.
>> >
>> > I'm of the opinion that the only way we should support ACPI is as a
>> > first-class citizen. We don't need to modify every driver and subsystem
>> > to support ACPI, only those necessary to support the minimal set of
>> > platforms using ACPI. ACPI is new in the arm space, and we can enforce
>> > quality standards on ACPI _now_ above what we're allowing for DT, and
>> > avoid future problems.
>>
>> Translated ACPI tables really don't make any sense at all. While the
>> models are similar in some regards, they are very different in others
>> and any translator (I suspect) would become very complicated to deal
>> with all the edge cases.
>
> If it turns out that we can't translate the ACPI tables dynamically, we
> could maintain a repository of "manually" translated DTSes for all the
> systems that do not ship with device tree.  Given that DTBs are fairly
> small, we could stick them all in an initrd or another binary loaded by
> the bootloader so that Linux and/or Xen can select the right one at boot
> time.

There are many possible ways to solve this, and I think we'll have to
wait and see how it ends up being used before we decide what to do.
Again, it's better to let things settle out for a few generations
instead of trying to support everything from the very beginning, given
that we're expecting turmoil in this area.


-Olof

ACPI vs DT at runtime

[Arnd Bergmann]

On Friday 15 November 2013, Olof Johansson wrote:
> So, I'm strongly urging that whatever the server guys try to do, it
> will in the end result in the ACPI data being translated into DT
> equivalents, such that the kernel only needs to handle data via DT.

I don't think that a translation layer is the answer, I see the problem
more in things that cannot be translated automatically. The parts that
are similar enough to allow translation could also just be handled by
a thin abstraction layer in the kernel, which I think we will see
on embedded x86 with DT-in-ACPI-syntax.

I think we can still treat ACPI on ARM64 as a beginner's mistake and
provide hand-written DT blobs for the few systems that start shipping
with that. The main reason for doing it in the first place was the
expected number of Windows RT servers, but WinRT isn't doing well
at the moment, so it's not unreasonable to assume it's going the same
way as WinRT tablets.

During the kernel summit, Grant (as one of the proponents of doing
ACPI on ARM) already mentioned that he only sees this as viable
on PC-like systems. My feeling is that when (if?) AMD or someone else
comes out with a server system where they basically replace the
x86 core with an ARM one but keep the system design, there won't
be much to describe in terms of internal components anyway, and also
no need to translate a lot of device information -- everything is
already a PCI device in that case and does not get handled through
the platform bus. However, until we see code or system-level specs
for such a system, I'd rather keep ACPI out of the ARM kernel so we
don't give people the wrong ideas.

	Arnd

ACPI vs DT at runtime

[Olof Johansson]

On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 15 November 2013, Olof Johansson wrote:
>> So, I'm strongly urging that whatever the server guys try to do, it
>> will in the end result in the ACPI data being translated into DT
>> equivalents, such that the kernel only needs to handle data via DT.
>
> I don't think that a translation layer is the answer, I see the problem
> more in things that cannot be translated automatically. The parts that
> are similar enough to allow translation could also just be handled by
> a thin abstraction layer in the kernel, which I think we will see
> on embedded x86 with DT-in-ACPI-syntax.

I'm not so sure that converting everything yet again to another
abstraction layer is a good solution. We've got one level of
abstraction today -- DT. And we've got the un-abstracted layer of
platform devices. Churning all drivers yet again seems like the wrong
way to do this. For things that we can pre-populate instead of adding
runtime abstraction, we should.

> I think we can still treat ACPI on ARM64 as a beginner's mistake and
> provide hand-written DT blobs for the few systems that start shipping
> with that.

I think we can do better -- we can ask those vendors to not ship ACPI
at all, and ship DT themselves (together with us for review, etc).
Especially since doing a broken ACPI implementation today _just for
us_ will just distract them. If they need one for RT, fine. As I
mentioned elsewhere, shipping a flashed DTB is no different from
shipping ACPI from a future-proof point of view; we'll end up
overriding either at some point once we figure out things better.

> The main reason for doing it in the first place was the
> expected number of Windows RT servers, but WinRT isn't doing well
> at the moment, so it's not unreasonable to assume it's going the same
> way as WinRT tablets.

It's sort of impossible to tell today. Since there are no ARM64
servers on the market, there's no market for RT on them. Nor are there
any machines that can be acquired to look at how they implemented
stuff. And the silicon vendors who have started doing some of this
work are mostly doing it in secret on their own.

> During the kernel summit, Grant (as one of the proponents of doing
> ACPI on ARM) already mentioned that he only sees this as viable
> on PC-like systems. My feeling is that when (if?) AMD or someone else
> comes out with a server system where they basically replace the
> x86 core with an ARM one but keep the system design, there won't
> be much to describe in terms of internal components anyway, and also
> no need to translate a lot of device information -- everything is
> already a PCI device in that case and does not get handled through
> the platform bus.

i2c devices and several other things are not probable, either are ECs
on LPC, etc. All of those mostly fall into the category of
simple-to-describe-in-any-format though.

> However, until we see code or system-level specs
> for such a system, I'd rather keep ACPI out of the ARM kernel so we
> don't give people the wrong ideas.

Strong agreement from me.


-Olof

ACPI vs DT at runtime

[Stefano Stabellini]

On Fri, 15 Nov 2013, Olof Johansson wrote:
> On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 15 November 2013, Olof Johansson wrote:
> >> So, I'm strongly urging that whatever the server guys try to do, it
> >> will in the end result in the ACPI data being translated into DT
> >> equivalents, such that the kernel only needs to handle data via DT.
> >
> > I don't think that a translation layer is the answer, I see the problem
> > more in things that cannot be translated automatically. The parts that
> > are similar enough to allow translation could also just be handled by
> > a thin abstraction layer in the kernel, which I think we will see
> > on embedded x86 with DT-in-ACPI-syntax.
> 
> I'm not so sure that converting everything yet again to another
> abstraction layer is a good solution. We've got one level of
> abstraction today -- DT. And we've got the un-abstracted layer of
> platform devices. Churning all drivers yet again seems like the wrong
> way to do this. For things that we can pre-populate instead of adding
> runtime abstraction, we should.

Simply using DT would help avoiding the awkward situation where a driver
of a device only works with one of the two description formats and not
the other.


> > I think we can still treat ACPI on ARM64 as a beginner's mistake and
> > provide hand-written DT blobs for the few systems that start shipping
> > with that.
> 
> I think we can do better -- we can ask those vendors to not ship ACPI
> at all, and ship DT themselves (together with us for review, etc).

They can ship with ACPI if they want to, what is important is that they
ship with device tree too.
Encouraging them to do that is definitely the right thing to do today,
regardless of the medium to long term ACPI strategy for the Linux
kernel.


> Especially since doing a broken ACPI implementation today _just for
> us_ will just distract them. If they need one for RT, fine. As I
> mentioned elsewhere, shipping a flashed DTB is no different from
> shipping ACPI from a future-proof point of view; we'll end up
> overriding either at some point once we figure out things better.

Well said.

ACPI vs DT at runtime

[Arnd Bergmann]

On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> On Fri, 15 Nov 2013, Olof Johansson wrote:
> > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Friday 15 November 2013, Olof Johansson wrote:
> > >> So, I'm strongly urging that whatever the server guys try to do, it
> > >> will in the end result in the ACPI data being translated into DT
> > >> equivalents, such that the kernel only needs to handle data via DT.
> > >
> > > I don't think that a translation layer is the answer, I see the problem
> > > more in things that cannot be translated automatically. The parts that
> > > are similar enough to allow translation could also just be handled by
> > > a thin abstraction layer in the kernel, which I think we will see
> > > on embedded x86 with DT-in-ACPI-syntax.
> > 
> > I'm not so sure that converting everything yet again to another
> > abstraction layer is a good solution. We've got one level of
> > abstraction today -- DT. And we've got the un-abstracted layer of
> > platform devices. Churning all drivers yet again seems like the wrong
> > way to do this. For things that we can pre-populate instead of adding
> > runtime abstraction, we should.

My point was not that everything would be good if we change the kernel
this way, it clearly wouldn't. I think the problem is more the parts
for which neither an automated translation nor a unified driver level
interface would work well.

> Simply using DT would help avoiding the awkward situation where a driver
> of a device only works with one of the two description formats and not
> the other.

Yes, but remember that Intel still have the problem on their embedded
systems, and will want to solve them.

For ARM Linux I agree that we're better off not having to change all
the drivers again for this, but we will have a growing number of
drivers that are shared with ACPI based x86 SoCs. At least there are
only one or two vendors of those chips ;-)

> > > I think we can still treat ACPI on ARM64 as a beginner's mistake and
> > > provide hand-written DT blobs for the few systems that start shipping
> > > with that.
> > 
> > I think we can do better -- we can ask those vendors to not ship ACPI
> > at all, and ship DT themselves (together with us for review, etc).
> 
> They can ship with ACPI if they want to, what is important is that they
> ship with device tree too.
> Encouraging them to do that is definitely the right thing to do today,
> regardless of the medium to long term ACPI strategy for the Linux
> kernel.

I'm skeptical about getting people to ship both, except if they
want to support multiple operating systems. For those vendors
we are talking to, we are possibly able to convince them to drop
ACPI for Linux based servers. The bigger problem is system vendors
we don't talk to. They are going to to do any number of crazy things
in their private kernels:

* Board files
* Hardcoded platform devices with no multiplatform support
* Custom hypervisor (EL2 or EL3) interfaces for probing
* FEX
* ACPI
* Some other firmware ported over from their MIPS products
* Incompatible Open Firmware
* Incompatible DT extensions
* ...

The only thing we really have a handle on is stuff that gets submitted
for inclusion into Linux. One would hope that this would include
any server platform, but I think the people trying get into that
market are still learning about how to do these things.

> > Especially since doing a broken ACPI implementation today _just for
> > us_ will just distract them. If they need one for RT, fine. As I
> > mentioned elsewhere, shipping a flashed DTB is no different from
> > shipping ACPI from a future-proof point of view; we'll end up
> > overriding either at some point once we figure out things better.
> 
> Well said.

+1

	Arnd

ACPI vs DT at runtime

[Olof Johansson]

On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
>> On Fri, 15 Nov 2013, Olof Johansson wrote:
>> > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > > On Friday 15 November 2013, Olof Johansson wrote:
>> > >> So, I'm strongly urging that whatever the server guys try to do, it
>> > >> will in the end result in the ACPI data being translated into DT
>> > >> equivalents, such that the kernel only needs to handle data via DT.
>> > >
>> > > I don't think that a translation layer is the answer, I see the problem
>> > > more in things that cannot be translated automatically. The parts that
>> > > are similar enough to allow translation could also just be handled by
>> > > a thin abstraction layer in the kernel, which I think we will see
>> > > on embedded x86 with DT-in-ACPI-syntax.
>> >
>> > I'm not so sure that converting everything yet again to another
>> > abstraction layer is a good solution. We've got one level of
>> > abstraction today -- DT. And we've got the un-abstracted layer of
>> > platform devices. Churning all drivers yet again seems like the wrong
>> > way to do this. For things that we can pre-populate instead of adding
>> > runtime abstraction, we should.
>
> My point was not that everything would be good if we change the kernel
> this way, it clearly wouldn't. I think the problem is more the parts
> for which neither an automated translation nor a unified driver level
> interface would work well.

Do you have predictions for what those areas would be? Chances are
that at least the initial ones can be handled with the methods we
already have today such as quirks and the like.

Once we've seen enough of them, we'll have more knowledge of what a
new solution really needs to cover. Speculating prematurely will
likely give us the wrong abstractions (and/or at too high a level,
causing extra work and churn for everybody). I think we agree that
holding off is the right answer, just maybe not (yet) what the actual
solution might be when we start to need it. :)

>> Simply using DT would help avoiding the awkward situation where a driver
>> of a device only works with one of the two description formats and not
>> the other.
>
> Yes, but remember that Intel still have the problem on their embedded
> systems, and will want to solve them.
>
> For ARM Linux I agree that we're better off not having to change all
> the drivers again for this, but we will have a growing number of
> drivers that are shared with ACPI based x86 SoCs. At least there are
> only one or two vendors of those chips ;-)

Well, you menion DT-in-ACPI above. If they're really exploring that
path then a lot will sort itself out from there. Making a decision to
hold off with ACPI for ARM will help get everybody on the same page if
they're already considering a solution along those lines.

>> > > I think we can still treat ACPI on ARM64 as a beginner's mistake and
>> > > provide hand-written DT blobs for the few systems that start shipping
>> > > with that.
>> >
>> > I think we can do better -- we can ask those vendors to not ship ACPI
>> > at all, and ship DT themselves (together with us for review, etc).

Yep, and together for review is a critical part. I'm not saying that
the ideal solution is a flashed DTB, but it's better than ACPI. A
flashed DTB that's _easy to update_ as part of an OS install would
probably be one of the best solutions we could ask for though.

>> They can ship with ACPI if they want to, what is important is that they
>> ship with device tree too.
>> Encouraging them to do that is definitely the right thing to do today,
>> regardless of the medium to long term ACPI strategy for the Linux
>> kernel.
>
> I'm skeptical about getting people to ship both, except if they
> want to support multiple operating systems. For those vendors
> we are talking to, we are possibly able to convince them to drop
> ACPI for Linux based servers.

+1. Especially if their initial focus is just on linux and not on
enabling RT on the same set of machines (with the same firmware).

> The bigger problem is system vendors
> we don't talk to. They are going to to do any number of crazy things
> in their private kernels:
>
> * Board files
> * Hardcoded platform devices with no multiplatform support
> * Custom hypervisor (EL2 or EL3) interfaces for probing
> * FEX
> * ACPI
> * Some other firmware ported over from their MIPS products
> * Incompatible Open Firmware
> * Incompatible DT extensions
> * ...

Given that we have a documented boot protocol today, it shouldn't
matter much if someone ports over some MIPS firmware (we did add OF
client interface to CFE at PA Semi, and that worked well for us :-).
Most of the others listed above can hopefully be avoided by us having
appropriate solutions in-kernel today that they can reuse. I.e. FEX
happened because DT didn't exist at the time.

ACPI is a big problem here in that sense: Vendors have been told to
use it, but there's no infrastructure, and even if it would be there
it would be immature and we don't really know what we want from it.

Board files and hardcoded devices are things we've dealt with already
and know what to do with, so I'm less worried about that. And finally,
custom firmware interfaces should hopefully be rare given the
reference PSCI implementation from ARM, but we can deal with it if we
have to.

> The only thing we really have a handle on is stuff that gets submitted
> for inclusion into Linux. One would hope that this would include
> any server platform, but I think the people trying get into that
> market are still learning about how to do these things.

Yes, we're likely to see some false starts, or even successful starts
done wrong. Hopefully we can catch them early and get them onto a
better track quickly. Especially once they realize they really do
want/need upstream support for their platforms.

I do hope we'll start to see more from the vendors that are working on
silicon soon, or things run the risk of getting really messy. :(

>> > Especially since doing a broken ACPI implementation today _just for
>> > us_ will just distract them. If they need one for RT, fine. As I
>> > mentioned elsewhere, shipping a flashed DTB is no different from
>> > shipping ACPI from a future-proof point of view; we'll end up
>> > overriding either at some point once we figure out things better.
>>
>> Well said.
>
> +1


-Olof

ACPI vs DT at runtime

[Arnd Bergmann]

On Sunday 17 November 2013, Olof Johansson wrote:
> On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> >
> > My point was not that everything would be good if we change the kernel
> > this way, it clearly wouldn't. I think the problem is more the parts
> > for which neither an automated translation nor a unified driver level
> > interface would work well.
> 
> Do you have predictions for what those areas would be? Chances are
> that at least the initial ones can be handled with the methods we
> already have today such as quirks and the like.

I think all DT references that take the form of <&phandle arg1 ...>
are problematic because in ACPI the same things tend to expressed
by a single number (irq, dma, gpio, ...) or just a reference with
no arguments (don't have an example here).

Another difference is things that are numbered on one side but
named on the other. In DT we  have an inconsistent mix of the two,
e.g. DMA requests must be named (per device) while IRQs must be
numbered (per device) and may additionally be named. 

Finally, anything that needs run-time interpretation of AML is
fundamentally hard because the AML would refer to objects that
don't exist when you don't boot from ACPI. This gets worse if you
need to pass ACPI identifiers into EL3 firmware. Because of this,
anything related to runtime PM scares me at the moment, because
there are two conflicting ways to do it: As we discussed before,
the correct way to do this in ACPI is to hide it all from the OS
in AML bytecode and EL2/EL3 firmware calls, but this may not be
possible on all systems and it prevents us from translating into
a format that the drivers can use to call our
regulator/clk/pmdomain interfaces.
Intel's embedded systems will likely get around this by defining
ACPI representations of our existing DT bindings for these
subsystems, which would be possible to translate automatically,
but it seems very silly to use those on servers.

> Once we've seen enough of them, we'll have more knowledge of what a
> new solution really needs to cover. Speculating prematurely will
> likely give us the wrong abstractions (and/or at too high a level,
> causing extra work and churn for everybody). I think we agree that
> holding off is the right answer, just maybe not (yet) what the actual
> solution might be when we start to need it. :)

Yes. Especially for the runtime-pm stuff, someone should probably try
both methods on a couple of systems and then decide which one of them
everybody should use. Unfortunately that alone is going to bind
reviewer resources and take a significant amount of time.

> >> Simply using DT would help avoiding the awkward situation where a driver
> >> of a device only works with one of the two description formats and not
> >> the other.
> >
> > Yes, but remember that Intel still have the problem on their embedded
> > systems, and will want to solve them.
> >
> > For ARM Linux I agree that we're better off not having to change all
> > the drivers again for this, but we will have a growing number of
> > drivers that are shared with ACPI based x86 SoCs. At least there are
> > only one or two vendors of those chips ;-)
> 
> Well, you menion DT-in-ACPI above. If they're really exploring that
> path then a lot will sort itself out from there. Making a decision to
> hold off with ACPI for ARM will help get everybody on the same page if
> they're already considering a solution along those lines.

Possibly, but x86 extending into deeply embedded may also have different
requirements to ARM extending into servers, even if both want to use
ACPI to get there. Some parts will overlap, others won't, and I suspect
that there is more in the second category than people are hoping for.

> >> > > I think we can still treat ACPI on ARM64 as a beginner's mistake and
> >> > > provide hand-written DT blobs for the few systems that start shipping
> >> > > with that.
> >> >
> >> > I think we can do better -- we can ask those vendors to not ship ACPI
> >> > at all, and ship DT themselves (together with us for review, etc).
> 
> Yep, and together for review is a critical part. I'm not saying that
> the ideal solution is a flashed DTB, but it's better than ACPI. A
> flashed DTB that's _easy to update_ as part of an OS install would
> probably be one of the best solutions we could ask for though.

Right: the assumption on the DT boot interfaces is that board designers
make mistakes and are working on moving targets, so we need ways to update
the DTB. By contrast, the assumption on ACPI is that server firmware
authors know what they are doing and you shouldn't let anyone else mess
with the ACPI bits because doing so might damage your hardware. We're
in trouble if the second assumption turns out wrong.

> > The bigger problem is system vendors
> > we don't talk to. They are going to to do any number of crazy things
> > in their private kernels:
> >
> > * Board files
> > * Hardcoded platform devices with no multiplatform support
> > * Custom hypervisor (EL2 or EL3) interfaces for probing
> > * FEX
> > * ACPI
> > * Some other firmware ported over from their MIPS products
> > * Incompatible Open Firmware
> > * Incompatible DT extensions
> > * ...
> 
> Given that we have a documented boot protocol today, it shouldn't
> matter much if someone ports over some MIPS firmware (we did add OF
> client interface to CFE at PA Semi, and that worked well for us :-).
> Most of the others listed above can hopefully be avoided by us having
> appropriate solutions in-kernel today that they can reuse. I.e. FEX
> happened because DT didn't exist at the time.
> 
> ACPI is a big problem here in that sense: Vendors have been told to
> use it, but there's no infrastructure, and even if it would be there
> it would be immature and we don't really know what we want from it.
> 
> Board files and hardcoded devices are things we've dealt with already
> and know what to do with, so I'm less worried about that. And finally,
> custom firmware interfaces should hopefully be rare given the
> reference PSCI implementation from ARM, but we can deal with it if we
> have to.

Yes, the only real worry is if someone does their own firmware interfaces
the way that Sony did on the PS3, which definitely requires custom
APIs in the kernel. All others can be handled in some way by ignoring
the provided interfaces and replacing them with DT. We might need some
boot wrapper for cases where someone ignored the documented boot
interfaces, but that would only be likely for systems designed for
another OS.
 
	Arnd

ACPI vs DT at runtime

[Jon Masters]

On 11/18/2013 03:45 AM, Arnd Bergmann wrote:
> On Sunday 17 November 2013, Olof Johansson wrote:

>> Yep, and together for review is a critical part. I'm not saying that
>> the ideal solution is a flashed DTB, but it's better than ACPI. A
>> flashed DTB that's _easy to update_ as part of an OS install would
>> probably be one of the best solutions we could ask for though.
> 
> Right: the assumption on the DT boot interfaces is that board designers
> make mistakes and are working on moving targets, so we need ways to update
> the DTB. By contrast, the assumption on ACPI is that server firmware
> authors know what they are doing and you shouldn't let anyone else mess
> with the ACPI bits because doing so might damage your hardware. We're
> in trouble if the second assumption turns out wrong.

In the server space we *never* ship updated ACPI tables in Red Hat
products, and we never would ship updated tables as part of the OS.
Platform data is platform data. It belongs to the vendor shipping the
system, never to the OS. Yes, there are workarounds for bugs but on the
whole you do in fact count on server vendors not to screw it up, and if
they do then it is up to them to ship a BIOS update for their hardware.

In the Fedora space, even on 32-bit, we tried to not get in the business
of shipping DeviceTree blobs (way back when) that should be shipped by
the platform, but alas many systems don't have flash to store the DTB.
Coupled with the moving target we're dealing with there...things have
been ugly. In the v8 server space, there will be no shipping of platform
data. It will be ACPI tables passed in via UEFI, never updated by the
OS, and owned wholly by the platform vendor.

Jon.

ACPI vs DT at runtime

[Russell King - ARM Linux]

On Mon, Nov 18, 2013 at 12:33:19PM -0500, Jon Masters wrote:
> In the server space we *never* ship updated ACPI tables in Red Hat
> products, and we never would ship updated tables as part of the OS.
> Platform data is platform data. It belongs to the vendor shipping the
> system, never to the OS. Yes, there are workarounds for bugs but on the
> whole you do in fact count on server vendors not to screw it up, and if
> they do then it is up to them to ship a BIOS update for their hardware.

... which is why my nightly autoboot tests regularly fail if I undock
and redock the laptop, and forget to manually rebind the serial port...
because the vendor supplied ACPI tables seem to be broken, and there's
zero interest from the vendor to fix such an issue.

They're certainly not going to fix it based on one report from an
end user using an obscure operating system which seems not to have
any support in mainline for such oeprations in any case.

Linux sucks sometimes - it's not all roses.

ACPI vs DT at runtime

[Olof Johansson]

On Mon, Nov 18, 2013 at 12:33:19PM -0500, Jon Masters wrote:
> On 11/18/2013 03:45 AM, Arnd Bergmann wrote:
> > On Sunday 17 November 2013, Olof Johansson wrote:
> 
> >> Yep, and together for review is a critical part. I'm not saying that
> >> the ideal solution is a flashed DTB, but it's better than ACPI. A
> >> flashed DTB that's _easy to update_ as part of an OS install would
> >> probably be one of the best solutions we could ask for though.
> > 
> > Right: the assumption on the DT boot interfaces is that board designers
> > make mistakes and are working on moving targets, so we need ways to update
> > the DTB. By contrast, the assumption on ACPI is that server firmware
> > authors know what they are doing and you shouldn't let anyone else mess
> > with the ACPI bits because doing so might damage your hardware. We're
> > in trouble if the second assumption turns out wrong.
> 
> In the server space we *never* ship updated ACPI tables in Red Hat
> products, and we never would ship updated tables as part of the OS.
> Platform data is platform data. It belongs to the vendor shipping the
> system, never to the OS. Yes, there are workarounds for bugs but on the
> whole you do in fact count on server vendors not to screw it up, and if
> they do then it is up to them to ship a BIOS update for their hardware.

And in x86 land these days, they mostly don't screw it up because they've been
doing this for years and years. On ARM we've got a dozen new vendors who have
never done any of this before (and neither have we), and we're all going to
screw it up. Denying that buys us nothing, planning for it in a manner that we
can recover from the worst screwups without paying for it forever is the best
way forward.

> In the Fedora space, even on 32-bit, we tried to not get in the business
> of shipping DeviceTree blobs (way back when) that should be shipped by
> the platform, but alas many systems don't have flash to store the DTB.

Well, duh, that was what we, as the kernel community, had mandated at
the time.

> Coupled with the moving target we're dealing with there...things have
> been ugly. In the v8 server space, there will be no shipping of platform
> data. It will be ACPI tables passed in via UEFI, never updated by the
> OS, and owned wholly by the platform vendor.

Everything is a moving target on ARMv8 today. ACPI isn't going to change that.

-Olof

ACPI vs DT at runtime

[Grant Likely]

On Mon, 18 Nov 2013 12:33:19 -0500, Jon Masters <jonathan@jonmasters.org> wrote:
> On 11/18/2013 03:45 AM, Arnd Bergmann wrote:
> > On Sunday 17 November 2013, Olof Johansson wrote:
> 
> >> Yep, and together for review is a critical part. I'm not saying that
> >> the ideal solution is a flashed DTB, but it's better than ACPI. A
> >> flashed DTB that's _easy to update_ as part of an OS install would
> >> probably be one of the best solutions we could ask for though.
> > 
> > Right: the assumption on the DT boot interfaces is that board designers
> > make mistakes and are working on moving targets, so we need ways to update
> > the DTB. By contrast, the assumption on ACPI is that server firmware
> > authors know what they are doing and you shouldn't let anyone else mess
> > with the ACPI bits because doing so might damage your hardware. We're
> > in trouble if the second assumption turns out wrong.
> 
> In the server space we *never* ship updated ACPI tables in Red Hat
> products, and we never would ship updated tables as part of the OS.
> Platform data is platform data. It belongs to the vendor shipping the
> system, never to the OS. Yes, there are workarounds for bugs but on the
> whole you do in fact count on server vendors not to screw it up, and if
> they do then it is up to them to ship a BIOS update for their hardware.

Agreed, shipping tables with RHEL is insane. If DT is used on the
servers, then the firmware needs to provide the DT, with the option to
override only when *absolutely* necessary.

g.

ACPI vs DT at runtime

[Mark Brown]

On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote:
> On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:

> > Simply using DT would help avoiding the awkward situation where a driver
> > of a device only works with one of the two description formats and not
> > the other.

> Yes, but remember that Intel still have the problem on their embedded
> systems, and will want to solve them.

Has it been confirmed that Intel are going with ACPI for their embedded
devices rather than SFI?  That would be nice given how awful SFI is and
I have heard that before but I'm not sure I've seen anything official.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/965930a8/attachment.sig>

ACPI vs DT at runtime

[Arnd Bergmann]

On Monday 18 November 2013, Mark Brown wrote:
> On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote:
> > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> 
> > > Simply using DT would help avoiding the awkward situation where a driver
> > > of a device only works with one of the two description formats and not
> > > the other.
> 
> > Yes, but remember that Intel still have the problem on their embedded
> > systems, and will want to solve them.
> 
> Has it been confirmed that Intel are going with ACPI for their embedded
> devices rather than SFI?  That would be nice given how awful SFI is and
> I have heard that before but I'm not sure I've seen anything official.

Possibly not all of Intel agrees to that, but I think that's what I've 
heard from Darrent Hart and David Woodhouse. I doubt you can get an
"official" confirmation about it. I also don't know if there is a follow-up
for the Intel CE4100 that started using DT[1].

	Arnd

[1] arch/x86/platform/ce4100/falconfalls.dts

ACPI vs DT at runtime

[Grant Likely]

On Mon, 18 Nov 2013 16:10:32 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 18 November 2013, Mark Brown wrote:
> > On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote:
> > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> > 
> > > > Simply using DT would help avoiding the awkward situation where a driver
> > > > of a device only works with one of the two description formats and not
> > > > the other.
> > 
> > > Yes, but remember that Intel still have the problem on their embedded
> > > systems, and will want to solve them.
> > 
> > Has it been confirmed that Intel are going with ACPI for their embedded
> > devices rather than SFI?  That would be nice given how awful SFI is and
> > I have heard that before but I'm not sure I've seen anything official.
> 
> Possibly not all of Intel agrees to that, but I think that's what I've 
> heard from Darrent Hart and David Woodhouse. I doubt you can get an
> "official" confirmation about it. I also don't know if there is a follow-up
> for the Intel CE4100 that started using DT[1].

Darren is using it to enable Minnowboard, and there is active work on
the GPIO, SPI and other subsystems to bring in ACPI support.

g.

ACPI vs DT at runtime

[Leif Lindholm]

Hi Olof,

Just in case this thread fails to reach its predicted triple-digits, I
would like to revisit something you mentioned in this original email
and then didn't expand on.

On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof Johansson wrote:
> The more I start to see early UEFI/ACPI code, the more I am certain
> that we want none of that crap in the kernel. It's making things
> considerably messier, while we're already very busy trying to convert
> everything over and enable DT -- we'll be preempting that effort just
> to add even more boilerplate everywhere and total progress will be
> hurt.
> 
> The server guys really want UEFI for their boot protocols,
> installation managers, etc, etc. That's fine, let them do that, but
> that doesn't mean we need to bring the same APIs all the way into the
> kernel.

There is zero dependency on ACPI in the UEFI support code, or indeed in
UEFI itself. Both runtime services support and stub loader have been
designed hardware-description agnostic.

Are you saying that we should not support the kernel interfaces to UEFI
on ARM*, or are you simply mentioning it in passing because it is the
bit responsible for populating the pointer to the ACPI tables?

/
    Leif

ACPI vs DT at runtime

[Olof Johansson]

Hej,

On Mon, Nov 18, 2013 at 3:25 PM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> Hi Olof,
>
> Just in case this thread fails to reach its predicted triple-digits, I
> would like to revisit something you mentioned in this original email
> and then didn't expand on.
>
> On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof Johansson wrote:
>> The more I start to see early UEFI/ACPI code, the more I am certain
>> that we want none of that crap in the kernel. It's making things
>> considerably messier, while we're already very busy trying to convert
>> everything over and enable DT -- we'll be preempting that effort just
>> to add even more boilerplate everywhere and total progress will be
>> hurt.
>>
>> The server guys really want UEFI for their boot protocols,
>> installation managers, etc, etc. That's fine, let them do that, but
>> that doesn't mean we need to bring the same APIs all the way into the
>> kernel.
>
> There is zero dependency on ACPI in the UEFI support code, or indeed in
> UEFI itself. Both runtime services support and stub loader have been
> designed hardware-description agnostic.
>
> Are you saying that we should not support the kernel interfaces to UEFI
> on ARM*, or are you simply mentioning it in passing because it is the
> bit responsible for populating the pointer to the ACPI tables?

Good question. UEFI and ACPI usually gets grouped together when they
really are separate (even though ACPI _without_ UEFI is highly
unlikely).

So, to clarify: What I meant with the above is that UEFI as a
bootloader is fine as far as I am concerned. I'm also in general ok
with the introduction of efivars that you're doing, etc.


-Olof

ACPI vs DT at runtime

[Leif Lindholm]

Hej,

On Mon, Nov 18, 2013 at 03:29:58PM -0800, Olof Johansson wrote:
> >> The server guys really want UEFI for their boot protocols,
> >> installation managers, etc, etc. That's fine, let them do that, but
> >> that doesn't mean we need to bring the same APIs all the way into the
> >> kernel.
> >
> > There is zero dependency on ACPI in the UEFI support code, or indeed in
> > UEFI itself. Both runtime services support and stub loader have been
> > designed hardware-description agnostic.
> >
> > Are you saying that we should not support the kernel interfaces to UEFI
> > on ARM*, or are you simply mentioning it in passing because it is the
> > bit responsible for populating the pointer to the ACPI tables?
> 
> Good question. UEFI and ACPI usually gets grouped together when they
> really are separate (even though ACPI _without_ UEFI is highly
> unlikely).
> 
> So, to clarify: What I meant with the above is that UEFI as a
> bootloader is fine as far as I am concerned. I'm also in general ok
> with the introduction of efivars that you're doing, etc.

Thank you for this clarification.

/
    Leif