Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common
From: Aaron Kling
Date: Thu Mar 19 2026 - 18:32:06 EST
On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@xxxxxxxxxxxx> wrote:
>
> On 3/11/26 2:44 PM, Aaron Kling wrote:
>
> > From: Teguh Sobirin <teguh@xxxxxxxx>
> >
> > This adds a base dtb of everything common between the AYN QCS8550
> > devices. It is intended to be extended by device specific overlays.
> >
> > Signed-off-by: Teguh Sobirin <teguh@xxxxxxxx>
> > Co-developed-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
> > 2 files changed, 1778 insertions(+)
> > […]
> > +/ {
> > + model = "AYN QCS8550 Common";
> > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
>
> Huh?.. All existing -common files are .dtsi includes without their own
> model/compatible, and the compile-time "dtbo" support is only used for
> EL2 where we want to apply the same thing to many many devices without
> polluting the tree with extra glue files. I don't see why this should be
> a "common device" with its own compatible string, and not just a dtsi.
>
> > […]
> > +&gpu {
> > + status = "okay";
> > +
> > + zap-shader {
> > + firmware-name = "qcom/sm8550/a740_zap.mbn";
> > + };
> > +};
>
> Please use the &gpu_zap_shader label.
>
> And does the generic zap actually just work?
>
> > […]
> > +&i2c0 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> > +
> > +&i2c4 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> > +
> > +&i2c12 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> If the individual devices actually use these busses, better to enable
> them inside of their .dts as well I think?
> > +&iris {
> > + status = "okay";
> > +};
> Works with generic firmware?
> > […]
> > +&pcie0 {
> > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> Current binding is to put these inside of the &pcieportN (renaming
> 'perst' to 'reset' which I just noticed I failed to do for one of my own
> files :D), see x1e78100-lenovo-thinkpad-t14s.dtsi for an example.
I tried making this change, but the pcie port failed to probe. I also
notice that all existing sm8550 devices still use the 'old' syntax.
Aaron