Message-ID: <CAMcHhXpPpQ175jiX3KbEVY7ATLghEzGU9EeQjx+zHkMs8vovzA@mail.gmail.com>
Date: Thu, 3 Apr 2025 02:06:30 +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 10:36, Aleksandrs Vinarskis
<alex.vinarskis@...il.com> wrote:
>
> 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

Small update,

Following initial work from Maud, I hacked around a bit and got HDMI
working _most of the times_ on cold boot. Far from complete, but this
proves the IC is indeed working as dumb bridge. At least non Zenbook
DP routed to qmphy, like hinted by DSDT.
I am guessing the HPD event comes too early, before AUX is ready for
EDID readout to be the cause of the hotplug almost never working,
since I can always readout EDID manually just fine. Will need to
investigate it a bit more.

Initial (dirty) change for Asus Zenbook A14 [1].

[1] https://github.com/alexVinarskis/linux-x1e80100-zenbook-a14/commit/90466cd004c3df5d717295ae7dcd5ed183701de0

>
>
>
> >
> > [...]
> >
> > [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