Re: [PATCH v6 3/3] arm64: dts: qcom: x1e80100-dell-xps13-9345: introduce EC

[Aleksandrs Vinarskis]

On Thursday, October 22nd, 2026 at 21:27, Liviu Nicoara <lnicoara@xxxxxxxxxxxx> wrote:

> On Thu, 22 Oct 2026 17:07:25 +0000, Aleksandrs Vinarskis wrote:
> > I do not think the left charger you identified is correct - how did
> > you arrive to that conclusion? Curious to compare to my method.
> 
> I am afraid my method was simpler and coarser than yours: one run per
> port, nineteen samples ten seconds apart, the charger feeding the
> system only (battery at 96 % and not charging), on a 7.2.6 kernel
> with all four GPIO channels in one DTB. The deltas over three minutes:
> 
> Channel                Left charger   Right charger
> 0x14b  AMUX2_GPIO          +1.6           -0.9
> 0x145  AMUX2_THM           +0.1           +3.4
> 0x146  AMUX3_THM           +0.8           -0.1
> 0x14a  AMUX1_GPIO          -0.2           +1.3
> 0x144  AMUX1_THM           -0.1           +0.2
> 0x148  AMUX5_THM           -0.2           +1.2
> 0x147  AMUX4_THM           +0.1           +1.8
> 0x14d  AMUX4_GPIO          +0.0           -0.0
> 
> The other channels fell or held while 0x14b rose, so it was not the
> board warming as a whole. But 1.6 C in three minutes, against your
> 2.3 C in ten seconds on the right, might mean that 0x14b is a sensor
> somewhere on the left side of the board, not necessarily on the left
> port's power path. Under SSD load it moved with 0x146 and fell with
> it in cool-down, which puts it close to the SSD. "Left charger" was
> my reading of the sign pattern. Your ten-second test is probably the
> better discriminator for a sensor on a power path. If nothing answers
> the left charger in ten seconds, the simpler reading is that the left
> port has no thermistor of its own among these seven.
> 
> > pm8550_gpio_02 does NOT clearly follow. In your test you have
> > waited multiple minutes, which is enough to heat up a larger
> > area on the motherboard.
> 
> Agreed. In your left run it was the only channel with a positive
> delta while the board drifted down, which is the same weak signal I
> had, and no more than that.
> 
> On the two AMUX3/AMUX4 GPIO channels: neither carries a thermistor
> on this unit, and your tables say the same for yours. 0x14c reads
> 130.048 C on every sample, the last row of the conversion table,
> where the driver clamps a voltage at or below the lowest it knows.
> Its input sits near 0 V. Windows' ADC configuration sets up only
> PM8550 GPIO3 and GPIO4 as analog inputs, for AMUX1 and AMUX2, so the
> pin behind AMUX3 is in its digital default, and PM8550's low GPIOs
> read back here as inputs with a 10 uA pull-down. 0x14d held 34.7 C
> within 0.1 C through both chargers and two load runs on this unit,
> and 35.8 to 36.0 C through every one of your tests, the hairdryer
> included. That is a biased pin, not a sensor. Both nodes can go.
> 
> > ADC5_GEN3_AMUX1_GPIO_100K_PU - Likely "lpddr5_therm"
> 
> I cannot separate 0x14a from 0x144 and 0x148 by heating. Under a
> one-core load reading a file from /dev/shm they rose 14.0, 14.4 and
> 14.2 C in lockstep, while the SoC's mem TSENS zone rose 20 C. Your
> RAM stress warmed every PMIC die by 1 to 4 C as well, so it does not
> single out 0x14a either. The three sit with the SoC; which one is the
> memory I cannot tell.
> 
> > Looks more like "sys_therm5" is the actual keyboard thermistor.
> 
> Consistent with what I see. 0x147 is the coolest of the seven, 29 C
> at idle, and nearly indifferent to board loads: it gained 2.0 C where
> 0x144 gained 9.2 under SSD I/O, and 2.5 C where 0x144 gained 14.4
> under the CPU load. A sensor away from the board, on the skin side,
> fits.
> 
> On 0x146: under four minutes of direct-I/O reads it rose 8.2 C
> against 10.0 C on the NVMe's own sensor, the largest share of any
> channel, and it fell at once when the load stopped while the
> SoC-side channels kept rising. Under the CPU-only control its share
> halved. I would keep "ssd_conn_therm" on it with partial confidence,
> but I will not argue if it goes with the others.
> 
> > Alternatively, I am leaning to drop the labels for anything we are
> > not sure about...
> 
> Or just give them pirate names. Jk.
> 
> Agreed. 0x145 as the right charger is what both of us measured.
> Everything else is a guess until the teardown. Numbering sys_therm
> from 1 matches Windows' SYS_THERM1 to 7, so that helps too.
> 
> One consequence on my side: the 9345 thermal-zones patch
> (20261006185557.23016-1-lnicoara@xxxxxxxxxxxx) names its zones
> chg-left on 0x14b and ssd on 0x146. I will respin it with neutral
> names for the zones that are not settled, so the two patches agree.
> 
> Happy to test a v7, including a lid close on the EC interrupt line,
> which my v6 run did not cover.
> 
> I love this laptop, but I will not open it up just to pinpoint the
> right thermistors' locations.

I went ahead and tested thermistors against their potential names.
Finding are available here:
https://github.com/alexVinarskis/linux-x1e80100-dell-tributo/blob/master/dell-xps13-9345-ec.pdf

TL;DR: with your correction of AMUX GPIOs to 1, 2 instead of 3, 4 most 
of the proposed labels are correct, except for left charging controller.
This thermistor is quite far away such that IMO it cannot be associated
with the charger. This perfectly explains the difference in heating up
rate we both observed.

I will adjust labels, address rest of the comments and respin series
shortly.

Regards,
Alex

> 
> Liviu
>