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

[Aaron Kling]

On Thu, Mar 12, 2026 at 10:19 PM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
>
> 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.

I did get a static ffmpeg binary to run and transcoding using v4l2m2m
hw codecs were working. So the generic firmware is fine.

Aaron