On Tue, 23 Sept 2025 at 21:32, Simon Glass <[email protected]> wrote: > > Hi Ard, > > On Fri, 19 Sept 2025 at 09:50, Ard Biesheuvel <[email protected]> wrote: > > > > > > The main difference is the level of abstraction: AML carries code > > logic along with the device description that can en/disable the device > > and put it into different power states. This is backed by so-called > > OperationRegions, which are ways to expose [abstracted] SPI, I2C and > > serial busses to the AML interpreter (as well as MMIO memory) so that > > the code sequences effectuating things like power state changes can be > > reduced to pokes of device register, regardless of how those are > > accessed on the particular system. > > > > On x86, many onboard devices are simply described as PCIe devices, > > even though they are not actually connected to any PCIe fabric. This > > solves the self-description problem, vastly reducing the number of > > devices that need to be described via AML. > > > > Also, there is a lot more homogeneity in how the system topology is > > constructed: on embedded systems, it is quite common to, e.g., tie the > > PHY interrupt line from the PCIe NIC to some GPIO controller that is > > not a naturally associated with that device at all, and this is > > something ACPI struggles with, and where DT shines. > > > > DT simply operates at a different abstraction level - it describes > > every detail of the system topology, including every clock generator > > and power source. This makes it very flexible and very powerful, but > > also a maintenance burden: e.g., if some OEM issues a v2 of some board > > where one clock generator IC has been replaced because the original is > > EOL, it requires a new DT and potentially an OS update if the new part > > was not supported yet. ACPI is more flexible here, as it can simply > > ship different ACPI tables that make the v2 board look 100% identical > > to the v1 as far as the OS is concerned. > > There is also the PEP addition you mention below, which I tend to see > as an admission that ACPI cannot handle the complexity of modern > systems. >
No. The problem is not the complexity itself, but the fact that it is exposed to software. x86 systems are just as complex, but they a) make more effort to abstract away the OS visible differences in firmware, and b) design the system with ACPI in mind, e.g., masquerade on-board peripherals as PCIe (so-called root complex integrated endpoints) so they can describe themselves, and use PCI standard abstractions for configuration and power management. > > > > > My Qualcomm laptop (using Linux) currently just reboots if it > > > gets too hot. > > > > > > > Not sure what you are trying to say here. Is this a dig at ACPI? Or > > Windows? Or both? > > Neither...I'm just pointing out the implications of ACPI for these > systems. Without a driver for the complex thermal (in this case) > trade-offs, they are not reliable. Indeed. > We need DT rather than ACPI. I tend to agree with you, but not for the reason you might think. The ACPI vs DT gets very religious and heated at times, but it is often like watching people arguing over whether hammers are fundamentally better than screwdrivers: it really depends a lot on whether you are using nails or screws, and ACPI is really a much better solution than DT for certain markets. However, the reason I think we need DT for these systems is the fact that there is prior art there. Many of these SoCs and subsystems (e.g., Qualcomm) are already shipping in major volumes with DT on Android phones, as well as Chrome OS, which are markets where performance and energy use are meticulously measured and managed. Any effort to bring up Linux+ACPI on those SoCs in parallel for a niche market such as Linux laptops is bound to be futile, and it is much better to build on the existing DT support to fill in the blanks. The problem, of course, is that the idea that we would maintain the DTs for these systems in the kernel tree is laughable. So either these systems need to ship as vertically integrated systems (Android, CrOS), or we need to muster the self discipline to create a DT description and *stick with it* rather than drop it like a brick as soon as the Linux minor version changes, so that we can support users installing their own Linux distros. _______________________________________________ boot-architecture mailing list -- [email protected] To unsubscribe send an email to [email protected]
