Results 1 to 10 of 10

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

  1. #1
    Join Date
    Jan 2007
    Posts
    16,819

    Default ACPI On ARM: Good Or Bad For Linux?

    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

  2. #2
    Join Date
    Jun 2009
    Posts
    694

    Default

    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.
    Last edited by Sonadow; 09-24-2014 at 02:09 AM.

  3. #3
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    929

    Default

    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.

  4. #4
    Join Date
    Jan 2014
    Posts
    335

    Default

    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)

  5. #5
    Join Date
    Oct 2011
    Posts
    45

    Default

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

  6. #6
    Join Date
    Jan 2014
    Posts
    335

    Default

    Quote Originally Posted by dibal View Post
    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)

  7. #7
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,627

    Default

    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.

  8. #8
    Join Date
    Oct 2011
    Posts
    45

    Default

    Quote Originally Posted by caligula View Post
    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?

  9. #9
    Join Date
    Sep 2014
    Posts
    3

    Default

    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.

  10. #10
    Join Date
    Sep 2014
    Posts
    1

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •