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

[Dmitry Baryshkov]

On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote:
> 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.

This needs to be explained in the commit message. But do you need then a
model/compatible in the default dtb?

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

Well, the only common part is the frequency & status, so not so much.

BTW: could you please uniformly add an empty line before the status
properties?

> 
> > > +&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.

You can use ffmpeg to verify the unit. It has v4l2m2m codecs.

-- 
With best wishes
Dmitry