I hope Qualcomm upstreams all the device tree kernel level stuff to Linux for every laptop model. One of the things I don't like about Arm Laptops is—for example—how even if a SoC is supported upstream, if the manufacturer does not upload a device tree for their device, then you're cooked.
I read that while these Snapdragon laptops do technically have UEFI + ACPI, the information they provide is not useful for Linux and is more coupled with Qualcomm's proprietary drivers on Windows. Therefore, device trees are needed on Linux (I could be wrong about the first part).
One option would be to implement the custom non-standard Qualcomm drivers that technically it needs to implement anyway, but with support for the UEFI/ACPI interface.
On Windows, Qualcomm ships custom drivers that override normal ACPI platform logic in various places, IIRC
Not an easily feasible option notably because the firmware ACPI tables are in part stubs - but work on hybrid ACPI/DT instead is possible.
One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.
Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.
_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.
This is actually misinformed, the discussion on the mailing list made it clear: there is NO full ACPI on these Windows ARM devices; they only use ACPI marginally and still require and provide device tree.
Phoronix should have revised that article, it's completely misleading.
hurricanepootis · · focus · HN ↗
I read that while these Snapdragon laptops do technically have UEFI + ACPI, the information they provide is not useful for Linux and is more coupled with Qualcomm's proprietary drivers on Windows. Therefore, device trees are needed on Linux (I could be wrong about the first part).
pantalaimon · · focus · HN ↗
<a href="https://www.phoronix.com/news/DT-ACPI-Hybrid-Mode-Linux" rel="nofollow">https://www.phoronix.com/news/DT-ACPI-Hybrid-Mode-Linux
p_l · · focus · HN ↗
On Windows, Qualcomm ships custom drivers that override normal ACPI platform logic in various places, IIRC
my123 · · focus · HN ↗
One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.
Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.
_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.
p_l · · focus · HN ↗
Of course my preferred setup would be for systems to actually ship compliant UEFI instead of Qualcomm shitshow
cromka · · focus · HN ↗
Phoronix should have revised that article, it's completely misleading.
lathiat · · focus · HN ↗
It’s crazy to need a million device trees on server or laptop class devices.
<a href="https://news.ycombinator.com/item?id=45086346">https://news.ycombinator.com/item?id=45086346