Re: [PATCH v2 2/2] arm64: dts: qcom: sm8550: Add support for Samsung Galaxy Tab S9 Wi-Fi

[Nizat Mikayilli <nacht@dxdmail.cc>]

On 10/12/26 4:14 PM, Konrad Dybcio wrote:
> On 10/5/26 9:47 PM, Nizat Mikayilli via B4 Relay wrote:
>> amplifiers and the VA macro probing. The microSD slot is described but
>> not yet tested; audio playback and capture were not exercised.
> 
> Please test them!

Done: microSD works (UHS-I SDR104, read/write verified, card detect
works), and so do speaker playback and DMIC capture. I'll update the
commit message in v3.

>> The display panel, touch, pen digitizer, cameras, battery/charging and
>> the wireless module are not described here; the latter needs additional
>> power sequencing and follows as a separate series.
> 
> Wi-Fi/BT should be a low-hanging fruit, see e.g. sm8550-qrd.dts

I tried a qrd-style description (wcn6855-pmu, PCIe0 with wifi@0, BT on
uart14). From a cold boot the chip doesn't come up: all PMU rails are on
and wlan-en is high, but there's no PCIe link and BT times out.

It works with the same nodes once the 11 WLAN PDC messages from the
downstream qcom,pdc_init_table are sent to AOP over the AOSS QMP during
power-up (tested with a hacked-up pwrseq-qcom-wcn). So this needs a
driver change first, and I'd like to send it separately.

Any preference on how to model that? I'd rather not put the raw strings
in DT, so a table in the driver seems better, but I'm not sure what to
key it on, since other boards don't need it.

>> +&i2c6 {
>> +	clock-frequency = <400000>;
>> +	status = "okay";
> 
> nit: let's keep a \n before 'status', file-wide

Will do.

>> +&tlmm {
>> +	/* GPIO36..39 are owned by TrustZone. */
> 
> Do we have an idea as to what they're connected to?

They're the QUP1 SE2 pins, and Samsung's DT reserves exactly these four.
Most likely it's the fingerprint sensor (Egis EL721), which is driven
from a TZ app. I'll mention that in the comment.

>> +/* Without a Type-C controller driver, keep the DWC3 in peripheral mode. */
> 
> Is there no pmic-glink in the firmware?

Doesn't look like it: no battmgr.jsn in the ADSP firmware, and
PMIC_RTR_ADSP_APPS never shows up. Type-C and charging go through an
SM5714 (charger, fuel gauge, PD) and an SM5440 over I2C, neither of
which has an upstream driver yet. I'll update the comment.

Thanks for the review,
Nizat