On Wed, 25 Sept 2024 at 00:15, Bjorn Andersson <andersson@xxxxxxxxxx> wrote:
>
> On Sat, Sep 21, 2024 at 06:33:33PM GMT, Aleksandrs Vinarskis wrote:
> > Initial support for Dell XPS 9345 13" 2024 (Tributo) based on X1E80100.
>
> Very nice.
>
> >
> > Working:
> > * Touchpad
> > * Keyboard (only post suspend&resume, i2c-hid patch WIP)
>
> Hitting scroll lock/unlock on a USB keyboard once fixes this issue for
> me as well. Looking forward to your WIP patch.
Thanks for your review.
Just submitted the series [3].
>
> > * eDP, with brightness control
> > * NVME
> > * USB Type-C ports in USB2/USB3 (one orientation)
> > * WiFi
> > * GPU/aDSP/cDSP firmware loading (requires binaries from Windows)
> > * Lid switch
> > * Sleep/suspend, nothing visibly broken on resume
> >
> > Not working:
> > * Speakers (WIP, pin guessing, x4 WSA8845)
> > * Microphones (WIP, pin guessing)
> > * Fingerprint Reader (WIP, USB MP with ptn3222)
> > * USB as DP/USB3 (WIP, PS8830 based)
> > * Camera
> > * Battery Info
>
> Adding the ADSP firmware gave me both battery status and info, but
> perhaps you're hitting the previously reported issue in pmic_glink?
>
Could you please share a bug report for the mentioned issue?
Were you running with [2] patch reverted or not?
Without reverting it, I cannot boot Ubuntu at all - it is spamming
qcom_battmngr errors and holding services back.
With patch reverted I do not get any battery related info, which I
guess makes sense. I tried applying [1], however it did help.
There are a few pmic_glink related errors in dmesg, so perhaps its related.
> >
> > Should be working, but cannot be tested due to lack of hw:
> > * Higher res OLED, higher res IPS panels
>
> I tried closing the lid and opening it again (which I believe is what
> was reported to not work on the other devices), and that seems to work
> fine.
>
> > * Touchscreen
>
> See below
>
> >
> [..]
> > diff --git a/arch/arm64/boot/dts/qcom/x1e80100-dell-tributo-13.dts b/arch/arm64/boot/dts/qcom/x1e80100-dell-tributo-13.dts
> [..]
> > +&i2c8 {
> > + clock-frequency = <400000>;
> > +
> > + status = "okay";
> > +
> > + touchscreen@0 {
> > + compatible = "hid-over-i2c";
> > + reg = <0x0>;
>
> Make this 0x10 (and update the unit address accordingly) and we have
> touchscreen.
Awesome, thanks for testing. Will add it.
Do you have an OLED variant, or high-res IPS? Will update description
when respinning to include it.
Thinking about it, perhaps depending on the OLED/IPS variant they have
different touchscreen models with different addresses? I find it weird
that the address was 0 as per ACPI.
> > +
> > + hid-descr-addr = <0x1>;
> > + interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + pinctrl-0 = <&ts0_default>;
> > + pinctrl-names = "default";
> > + };
> > +};
> [..]
> > +&mdss_dp3 {
> > + compatible = "qcom,x1e80100-dp";
>
> This isn't needed, right?
Indeed. Will fix it.
>
> [..]
> > +&uart21 {
>
> This fails to probe, because we don't have an alias for it, which in
> turn prevents sync_state on interconnects...
>
Indeed. Will fix it.
Thanks,
Alex
[1] https://lore.kernel.org/all/20240918-x1e-fix-pdm-pdr-v1-1-cefc79bb33d1@xxxxxxxxxx/
[2] https://lore.kernel.org/all/20240708-x1e80100-pd-mapper-v1-1-854386af4cf5@xxxxxxxxxx/
[3] https://lore.kernel.org/all/20240925100303.9112-1-alex.vinarskis@xxxxxxxxx/
> > + compatible = "qcom,geni-debug-uart";
> > + status = "okay";
> > +};
> > +
>
> Regards,
> Bjorn
