Message-ID: <CAMcHhXrcvsKtZnHC5gKFh3nc_XKQKaLdBbnQA6J_rBdUxxP27w@mail.gmail.com>
Date: Wed, 2 Apr 2025 10:36:19 +0200
From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
To: Maud Spierings <maud_spierings@...mail.com>
Cc: abel.vesa@...aro.org, andersson@...nel.org, conor+dt@...nel.org, 
	devicetree@...r.kernel.org, gregkh@...uxfoundation.org, 
	heikki.krogerus@...ux.intel.com, johan+linaro@...nel.org, 
	konrad.dybcio@....qualcomm.com, konradybcio@...nel.org, krzk+dt@...nel.org, 
	krzysztof.kozlowski@...aro.org, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org, lumag@...nel.org, 
	robh@...nel.org
Subject: Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus
 Zenbook A14

On Wed, 2 Apr 2025 at 08:30, Maud Spierings <maud_spierings@...mail.com> wrote:
>
> > On Tue, 1 Apr 2025 at 23:15, Konrad Dybcio
> > <konrad.dybcio@....qualcomm.com> wrote:
> >>
> >> On 4/1/25 8:05 PM, Aleksandrs Vinarskis wrote:
> >> > On Tue, 1 Apr 2025 at 17:59, Konrad Dybcio
> >> > <konrad.dybcio@....qualcomm.com> wrote:
> >> >>
> >> >> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> >> >>> Initial support for Asus Zenbook A14. Particular moddel exists
> >> >>> in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
> >> >>>
> >> >>> Mostly similar to other X1-based laptops. Notable differences are:
> >> >>> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
> >> >>>   and Qualcomm FastConnect 7800 on UX3407RA
> >> >>> * USB Type-C retimers are Parade PS8833, appear to behave identical
> >> >>>   to Parade PS8830
> >> >>> * gpio90 is TZ protected
> >> >>
> >>
> >> [...]
> >>
> >> >>
> >> >>> +&spi10 {
> >> >>> +     status = "disabled";
> >> >>> +
> >> >>> +     /* Unknown device */
> >> >>> +};
> >> >>
> >> >> Does the device crash if you enable this bus? Keeping it 'okay' would
> >> >> make it easier for folks to poke at it
> >> >
> >> > It does boot just fine, but does not initialize:
> >> > ```
> >> > geni_spi a88000.spi: Invalid proto 9
> >> > ...
> >> > qnoc-x1e80100 interconnect-1: sync_state() pending due to a88000.spi
> >> > ...
> >> > ```
> >> >
> >> > I only quickly checked that 9 is indeed invalid state, iirc should've
> >> > been 2. But haven't looked deeper into it, so left it disabled. So I
> >> > thought best to leave it off for now. Unless you prefer to drop it
> >> > altogether?
> >>
> >> That means this QUP is configured to work as a QSPI host, which is not yet
> >> supported upstream. I looked at the DSDT you submitted to aa64-laptops, but
> >> there doesn't seem to be anything connected there, perhaps it's loaded at
> >> runtime. Since your keyboard and touchpad work, maybe it's a touchscreen?
> >>
> >
> > Indeed it is just defined without anything attached. I am suspecting
> > it also may be just leftover, won't be the first one...
> > No, this particular laptop doesn't have a touchscreen in any of the
> > three screen configurations announced.
> >
> > It also does not have a fingerprint reader, nor hardware TPM2.0 (yet
> > SPI11 typically used for it is still TZ protected :). EC seems to be
> > over i2c5. Asus's touchpad supports some fancy gesture controls, but
> > there is in fact another 'extra' hidraw device 'hdtl', I assume that's
> > the one. No sdcard reader.
> > Only other still unsupported features are audio (i guess unlikely that
> > they used different smart amp?), camera (ov02c01, pm8010, so also no)
> > and DP-HDMI bridge PS185HDM, which from what I can guesstimate is i2c.
>
> I actually managed to contact someone about the ps185hdm as it is also
> used in my asus vivobook s15. But from what they told me it is a dumb
> bridge that does not require any further configuration. I have tried
> getting it to work but I've had no luck yet. I did find a hpd gpio at
> tlmm 126.
>
> I currently have just tried ignoring its existence and describing a non
> existent dp-connector with the hpd gpio hooked up to mdss_dp2_out but no
> luck. I get a timeout on the aux bus communication I think, so something
> is blocking that still.

I think it was your messages that I saw on IRC of aarch64-laptops
then. Can confirm both HPD on tlmm, and lack of any i2c devices on
newly created virtual bus.

>
> I think it may just be some regulator or something required to actually
> power up the ps185hdm

That was my conclusion as well. Would you mind following up with them,
if they could disclose the amount of voltage supplies the IC is
expecting? if it's 1 or 2, it's rather easy to bruteforce all unused
pin combinations. If it's more than that, it's only reasonable to
enable all unused GPIOs to high at once, which I wouldn't do tbh :)

The weird thing is that according to a rather simplified publically
available diagram, HPD is actually propagated through the PS185,
implying that bridge is on. It could be that IC requires multiple
supplies, hence Aux bus is not working, but in my experience these
devices typically don't start until all of the required supplies are
up.

>
> from my correspondence:
> `
> Hi Maud,
>
> There is no “enable pin” on the PS185 but there are several GPIO’s. The
> FW associated with the device is programmable so the manufacturer of the
> motherboard you are using may have requested a special feature (such as
> an enable pin on one of the GPIO) to be added by Parade. If that’s the
> case then you would need to contact the motherboard manufacturer to find
> out more details.
>
> Hot plug events are normally routed through the DP_HPD pin but, as noted
> above, it’s possible that the motherboard manufacturer asked for this to
> be replicated on the GPIO pin.
> `
>
> some messing around of me in the dts can be found here: [1]

I think, you would also need to enable usb_1_ss2 combo phy, afaik only
mdss3 (for eDP) has a dedicated DP phy, for the rest it's a combo
qmpphy. Konrad could probably confirm?
Once i2c/aux works, maybe we would also need a small driver to set phy
to DP mode, as afaik pmic-glink handles these. Just hypothesis though.
I have tried adding a dummy "dp-connector" like you did, but as a
child node to pmic-glink, hoping that it would handle the alt mode,
but it is probably not that easy :)

Would be happy to cooperate on debugging this offline.

Alex



>
> [...]
>
> [1]:
> https://github.com/SpieringsAE/linux/blob/wip/x1e80100-6.14/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts
>
> kind regards,
> Maud

Powered by blists - more mailing lists