Matthew GarrettEvery single ACPI vs Device Tree argument needs to start with the observation that I can boot a modern Linux kernel on an arbitrary x86 board from 1998 and it will probably suspend and resume correctly, and I can't do that with an arbitrary Arm board from 2026
Cassandrich@mjg59 The arm folks have consistently refused to use device tree the way it's supposed to work since the beginning, treating the dtb like something unstable you're supposed to upgrade with the kernel rather than an immutable hardware description that should be baked in rom. This is their fault, not something intrinsic to device tree.
Andrew ZonenbergWhy ACPI?
"Why does ACPI exist" - - the greatest thread in the history of forums, locked by a moderator after 12,239 pages of heated debate, wait no let me start again.<br /><br />Why does ACPI exist? In the beforetimes power management on x86 was done by jumping to an opaque BIOS entry point and hoping it wo
Martin Roukala (né Peres)@mjg59 @azonenberg @dalias And I want the ARM world to move away from the insanity that is the current DTBs:
* They suck at describing the hardware, they are more a Linux config file: Linux forks (vendor trees) will always have incompatible ones because upstream doesnt care about compatibility...
* Not only every SoC needs to be supported, every board needs its own broken DTB... Which leads to board-specific brokeness for SoC-provided features!
* Good mainline support never comes before the effective end of life of the device... Even with big companies working on it with significant resources!
By allowing DTBs to exist, vendors could start making SoCs very very diverse without caring about the software ecosystem. This is nuts and this insanity needs to be stopped by introducing discoverable buses and blocks, then add per-vendor platform drivers as a glue. Something akin to ACPI would then be introduced for board-specific customization.
You can keep the compatibles and the equivalent of a DTB to document if blocks are user-visible or not (so that he is not exposed to the user otherwise). New SoCs should finally be mostly backwards compatible, allowing basic release-day upstream support, and reducing the need for vendor trees, or the cost of mainlining.
Christian Gmeiner@mupuf @mjg59 @azonenberg @dalias why should upstream care about compatibility with downstream vendor forks? Vendor forks are a nightmare and often everything to support a soc is just hacked together piece of something.
Also every board has some board-specific layouts and so we need separate dts, as dts describe hardware.
And comparing dts with ACPI is unfair.. like comparing apples to pears.
@austriancoder @mjg59 @azonenberg @dalias Right, I wasn't being clear here.
Upstream should care because if DTBs WERE a hardware description language, it could be standardized and would not depend on driver *implementations*. It could then be embedded by the vendor in the firmware and new boards could get release-day upstream support.
In the x86 world, we have essentially what I recommended: Discoverability using pci vendor: device, then a "platform" driver called amdgpu/nouveau/whatever, and a vendor-specific board description language in the video bios. And then no need for per-gpu DTBs.
IMO, hardware description is the vendor's job. Upstream should just take it and roll with it. The fact it doesn't is IMO a failure of the model and a proof than describing the hardware like that is a fool's errand. Unfortunately, vendors have little incentive to keep on maintaining their tree, so that leads to the terrible user experience: either use outdated hardware with good upstream support, or use outdated vendor trees on newer hardware. Everybody loses...
As for ACPI vs DTB comparison: they are meant to solve roughly the same problem, aren't they? Abstract away hardware differences from the OS PoV so that the same kernel binary can work on two boards.
@mupuf @austriancoder @azonenberg @dalias Not quite - DTB is supposed to provide a full description of the available hardware and the metadata required to drive it. ACPI can do that, but is really intended to provide an abstract interface to the underlying hardware such that the OS doesn't need to know what the available hardware is or how it's wired up.
@mjg59 @austriancoder @azonenberg @dalias indeed. I would call ACPI a pragmatic approach: describing hardware in a generic way is pretty much impossible, so let's separate concerns and let the firmware provide the scripts to run when wanting to do X.
This means it is hard to teach new tricks to old boards without the vendor providing firmware updates, but you gain a much more consistent user experience and release-day upstream support.
If we could have ACPI-like support for release day support, then open firmware + dtb-based solution with upstream later on, I guess it would be the best of both worlds and upstream Linux could be used at all time... We'll see how system ready will turn out, maybe it could achieve 50% of this dream?
@mupuf @austriancoder @azonenberg @dalias In theory there's no reason people can't provide device-tree like data that passes chunks of ACPI functionality over to an actual driver - I don't think there's ever been enough need for someone to bother, but it's possible. What we see in the Qualcomm laptop case is people trying to solve it all with DT and us ending up with machines with missing functionality as a result.