Comment by my123
4 years ago
For arm: anything that runs Windows on Arm64 uses UEFI + ACPI, making stuff easier on that front.
Linux drivers for Qualcomm SoCs don't have extensive ACPI bindings at this point in time though, making the use of a separate devicetree necessary for full functionality. This will be mostly ironed out with time I suppose.
Didn't Linux developers say that Qualcomm's ACPI tables are a horrific Windows-specific mess that has close to zero standard PNP* things?
> Windows-specific mess that has close to zero standard PNP* things
Those are hardware dependent platform devices. Qualcomm didn’t have another option. (Nor do other manufacturers really)
On x86, a virtual PCIe bus abstraction is heavily used, which is not the case for those SoCs.
(And well, if Linux wants to boycott full support of their SoCs, their choice. They just can’t blame Qualcomm anymore at that point.)
Another thing of note is the use of a PEP (power management plug-in) in the OS instead of having power management done in AML. The ACPI spec allows a manufacturer to do this. It isn’t used only by Qualcomm, but is totally unsupported on Linux today.
Manufacturers have the option of producing standards-compliant goddamn hardware! Say for PCIe, even if it's a buggy and quirky implementation but it does support ECAM, you can still expose a PNP0A08 and deal with quirks in firmware (hello Socionext/Marvell/NXP).
> PEP (power management plug-in) in the OS […] ACPI spec allows a manufacturer to do this
Doing management in AML is almost the whole point of ACPI. Microsoft pushing this PEP thing into the ACPI spec is bad. This is the "letter" of ACPI now, unfortunately, but it's very much against the original "spirit" of ACPI :/
1 reply →