Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode

[Hans de Goede <johannes.goede@oss.qualcomm.com>]

Hi Bjorn,

On 29-Jun-26 4:27 AM, Bjorn Andersson wrote:
> On Tue, Jun 23, 2026 at 04:52:13PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Currently as soon as the kernel boots with a populated DT provided then
>> the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
>> gets disabled. On WoA Snapdragon laptops where the factory Windows OS
>> actually boots using these tables this is not necessarily desirable.
>>
>> It might still be interesting to at least parse the ACPI tables and make
>> the ACPI fwnodes available for device-drivers to use. I call this DT-ACPI
>> hybrid mode.
>>
>> This mainly is an experiment for now and possibly a method for accelerating
>> the ongoing effort to run Linux on currently available Snapdragon laptops.
>>
>> On current laptops Linux cannot boot using ACPI due to some information
>> missing from the ACPI tables. People are working on changing this so that
>> for future WoA Snapdragon laptops Linux can boot using ACPI only without
>> requiring Devicetree.
>>
>>
>> There are a couple of scenarios where DT-ACPI hybrid mode is useful:
>>
>> a) This leads to a populated /sys/firmware/acpi/tables allowing one to run
>> acpidump, which is useful to grab info from the ACPI tables when e.g.
>> creating a DT for a new laptop model.
> 
> This depends on the laptop in question sufficiently following the
> reference design, such that you actually have a good enough base DT to
> find those i2c-hid devices...

I agree that even just for i2c-hid devices this series seems to be something
which will not "just work" for all models because vendors seem to just
pick a random i2c bus for the HID devices.

Not sure why you replied this to item "a)" of my enumeration of why the
hybrid mode stuff may be useful. I think this comment of yours belongs
under "c)" ?   "a)" is just about populating /sys/firmware/acpi and
/sys/bus/acpi/devices without any other functional changes.

This difference is important because unlike the rest of the series
I would like to get "a)" upstream eventually (maybe even soon) because
it is a useful debugging tool when writing devicetrees for new models.
 > E.g. on the Glymur-based Asus Zenbook A14 that I recently brought up,
> keyboard sits on a previously unused I2C bus - something I wouldn't know
> without first acpidumping.

Ack.

>> As a bonus /sys/firmware/acpi/bgrt
>> is also populated allowing the boot-splash to show the vendor logo.
>>
>> b) It might be useful for device-drivers to be able to access ACPI data
>> for the device even when running in DT mode. E.g. Srini Kandagatla first
>> got me thinking about this because he wants to use the ACPI MIPI SDCA
>> tables for audio codec routing when booting Linux on Windows Qualcomm X2
>> (Glymur) laptops.
>>
> 
> As I argued during last year's Plumbers, I'm strongly against this, for
> anything but prototyping/experimentation.
> 
> Specifically something like the MIPI SDCA tables, are we going to define
> an ABI across DT/ACPI such that we now require the hybrid system in
> order to build a Glymur-based DT-based product?

I think re-using MIPI SDCA tables rather then having to manually recreate
the same info for each laptop model in DT is actually a good idea. This should
make bringing up sound on Glymur laptops much easier.

I know you worry about a theoretical embedded devicetree only use-case of
Glymur in which case we will need to create DT-bindings for audio then since
there won't be MIPI SCDA tables there.

But your suggested solution to this seems to be to do the work to create
the DT bindings now *and* then also add a lot of work on top to create
the very much non trivial dts bits for each laptop model.

So what you're suggesting is more work now + more work per laptop model
to avoid doing the same amount of work (but then not per model) later
in case an embedded Glymur use-case which is DT only pops up.

As such I agree with Srini that re-using the SCDA tables seems like
a good idea for the Windows laptops use-case.

Just another random thought which popped up in my mind for "b)",
it might be interesting to use the ACPI I2C-HID _DSM to get
the "hid-descr-addr" in case where there are 2 alternative touchpad/
touchscreen sources which share there I2C client address, since we
currently rely on different sources having different I2C addresses
and then I2C-HID silently failing to probe the non existing one.

Actually checking the _STA method for second sources for some components
might be an interesting use-case for the second-source case in general.

>> c) It is also possible to go truely hybrid and use ACPI to instantiate
>> some of the kernel device objects representing the hardware. For example
>> the last patch in this RFC series switches to using ACPI instantiation for
>> the I2C clients for the keyboard and touchpad on the Snapdragon X1E Lenovo
>> ThinkPad T14s gen 6.
>>
> 
> Which introduces the very shortcomings that are a key part of why we
> don't just run off ACPI in the first place today.
> >> d) This may help identify shortcomings in the current ACPI tables which
>> need to be fixed to allow future laptop generations to use ACPI only.
>>
> 
> This is worth looking further at.
> 
>>
>> Upstreaming of these patches (to upstream or not to upstream?).
>>
>> 1. The first couple of patches in this series mainly implement a) + b) from
>> above. This seems like something genuinely useful to have; and except for
>> missing DT-bindings for hybrid mode this seems mostly ready to go upstream.
>>
>> 2. I see c) as a way to slowly evolve support for current Snapdragon laptops
>> to use more and more info from ACPI and get closer to a point where we only
>> need a single DT describing the SoC and any info related to laptop model
>> specific bits outside of the SoC can be read from the ACPI tables.
>>
>> As mentioned above work is being done to have Linux boot on future laptop
>> generations using ACPI only, so all this applies to currently available
>> Snapdragon laptop generations only.
>>
>> The question is what to do wrt upstreaming patches necessary for c) though
>> (patches 7-12) are we going to allow new Devicetree files for not yet
>> supported laptop models to partially rely on ACPI?
>>
>> The current demo ACPI usage in this RFC series just instantiates I2C-HID
>> devices from ACPI. More interesting would be to hookup the embedded
>> controller (EC) handling in the ACPI tables instead of having to write
>> a special EC driver for each laptop model separately. For the EC parts
>> I believe that it might be worthwhile to implement c).
>>
> 
> Wiring up the EC is the one use case that I can think of where the
> hybrid mode would be really interesting, as a hack around the need to
> write custom device drivers for each one.

Ack, I have experimenting with trying to hookup the T14s EC through ACPI
on my DT-ACPI hybrid project TODO list, not sure when I'll get around
to this.

I agree with you that that likely is the most interesting use-case and
any further discussion on if we want hybrid support other then "a)" above
upstream should wait to see how the EC experiment goes.

Regards,

Hans