Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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.

My use case for these devices is Android, using a single base dtb and
variant dtbo's in a single software build. Given the aosp boot image
v4 setup, using individual dtb's would require different vendor_boot
images, which would require multiple build targets. This setup allows
for my use case, while also having individual dtb targets for a
standard Linux use case. To my knowledge, the final device specific
dtb from this is the same as a dtb using a common dtsi.

> > […]
> > +&gpu {
> > +     status = "okay";
> > +
> > +     zap-shader {
> > +             firmware-name = "qcom/sm8550/a740_zap.mbn";
> > +     };
> > +};
>
> Please use the &gpu_zap_shader label.

Ack.

> And does the generic zap actually just work?

The devices boot and the gpu works, so whatever code path is being
used works. These devices are unfused, and based on what I understand
a zap shader to be, switching a gpu from secure mode to non-secure,
I'm not sure it's needed at all. I have not tested just not setting,
though.

> > […]
> > +&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?

I can move them. I think the idea was that all variants do use these,
but for different hardware, so might as well commonize this part. This
part existed before I started working on the devices, so I can't say
for sure.

> > +&iris {
> > +     status = "okay";
> > +};
> Works with generic firmware?

I have not been able to verify this. Unfortunately, there is not an
aidl v4l2 c2 hal for aosp. If the expectation is that device specific
firmware is needed, even for unfused devices, I can drop this section
until I am able to use it. Or maybe Teguh could chime in if this works
on ROCKNIX.

> > […]
> > +&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.

Ack.

> > […]
>
> Thanks for this work, very cool overall!
>
> ~val

Aaron