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.