ACPI vs DT at runtime

On Tuesday 19 November 2013, Mark Rutland wrote:

On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote:

quoted

quoted

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...

quoted

quoted

quoted

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.

quoted

quoted

quoted

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