ACPI On ARM: Good Or Bad For Linux?

[phoronix]

Phoronix: ACPI On ARM: Good Or Bad For Linux?

Linux kernel developers currently have mixed feelings whether ACPI on ARM will be beneficial or not...

http://www.phoronix.com/vr.php?view=MTc5NTM

[Sonadow]

Bad or not, we still need a standard, or at least a reference implementation for power management on Linux.

Even if ACPI is the spawn of satan, it is still a long-established standard. I'd much rather have a bad standard that everyone needs to adopt, and fix things along the way as opposed to having a ton of other incompatible standards competing to become the de-facto standard for power management on ARM, because we all know how that will turn out.

And the icing on the cake is that Linux (ok, Android) is in the rare position where it can dictate standards and conventions to users and partners because of its dominant position in the ARM-powered smartphone space. After all, ACPI has worked out well for desktops, notebooks and x86 slates / tables, so we have reason to be optimistic that ACPI on ARM will eventually turn out fine and dandy.

I say we go for ACPI on ARM.

[chithanh]

I think the solution to the problem is to standardize on firmware which is open source as well. That way it can be easily fixed if something breaks due to undefined behavior, if necessary by the user. Which interface is then used between kernel and firmware becomes a secondary concern.

Chromebooks use Coreboot as firmware and OLPC XO-1.75/XO-4 use Open Firmware (IEEE 1275), either would be a good choice.

[caligula]

It's becoming clear that Arm power draw grows so need for power management is bad. People have suggested UEFI and ACPI. So why not. They're not that big either compared to sd card size nowadays (=512 GB)

[dibal]

ACPI is too big for embedded Stuff. What are the advantages of ACPI against coreboot/uboot and devicetrees?

[caligula]

ACPI is too big for embedded Stuff. What are the advantages of ACPI against coreboot/uboot and devicetrees?

ARM is not only embedded anymore. It also runs servers and phones. Phones have 4x2.5 GHz cores and 4 GB of RAM and 512 GB SD cards (+ 32 GB eMMC)

[schmidtbag]

I think Matthew made a pretty good argument, though I don't think implementing ACPI would be anywhere near as difficult as x86. Sure, we don't have Windows for a reference, but ARM platforms are far less complex than x86. It wouldn't surprise me if ARM only needs 20% of the ACPI features x86 uses, so couldn't you just take those and use them as a reference?

To me I think the more important question is if this is worth the time and effort. ARM doesn't take up much power when under full load. Considering how weak it is in a processing perspective, I think something like this is wasting what few resources it already has, and, will not make a significant difference. For example, if you have a small/weak car like a Prius and drive on the highway, I'm sure the motor is already under a lot of stress and can't handle much more speed/weight, even though it is more efficient than the average car. Then you can look at a large flatbed truck, which could probably go twice as fast with 10x the payload as the prius, but even at a slower speed it would still use up more gas. Finding ways to optimize the truck is important, because the lesser its payload, the less efficient it becomes. Finding ways to optimize the prius is almost pointless, because it's near max capacity and is still more efficient. You can't really increase the efficiency of something that is already pushed to its limits.

Obviously there's a lot more to it than this, but this is just 1 example of why I think ACPI isn't worth the time and effort for ARM.

[dibal]

ARM is not only embedded anymore. It also runs servers and phones. Phones have 4x2.5 GHz cores and 4 GB of RAM and 512 GB SD cards (+ 32 GB eMMC)

If ACPI gives me no advantage then the bigger footprint of ACPI is a big disadvantage. Why stay with bloat if it gives me nothing?

Is ACPI free of proprietary rights?

[sound5]

Linus Torvalds has to deal with this insanity a lot. He's pretty up front about the pain:

EFI is this other Intel brain-damage (the first one being ACPI). It's
totally different from a normal BIOS, and was brought on by ia64, which
never had a BIOS, of course.

Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now
have x86 machines with EFI as the native boot protocol.

The original EFI code in the kernel basically duplicates all the BIOS
interfaces (ie everything that looks at a memory map comes in two
varieties: the normal and tested BIOS e820 variety, and the usually broken
and hacked-up EFI memory map variety).

Translating the EFI memory map to e820 is very much the sane thing to do,
and should have been done by ia64 in the first place. Sadly, EFI people
(a) think that their stinking mess is better than a BIOS and (b) are
historically ia64-only, so they didn't do that, but went the "we'll just
duplicate everything using our inferior EFI interfaces" way.

- LKML, July 2006

Or this one:

ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce.

- Cruise, Nov 2003

I've also had to deal with these standards. They have good sounding intentions and totally fail to address the real problem.

[Unnamed]

First, ACPI != uboot or coreboot.

uboot and coreboot are for loading the os or an osloader, but not for power management and such things.

The advantage of ACPI is e.g. power management which is at the moment handled from a board specific driver in the kernel. With ACPI one would only need one driver for power management and would support all boards with ACPI support. I think this is an advantage and it?s something the ARM platform needs!

It would be like on x86, one kernel and drivers for the devices, but not drivers for every board.