Re: [PATCH v7 3/6] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

On Thu, Apr 30, 2026 at 6:59 PM Val Packett <val@xxxxxxxxxxxx> wrote:
>
>
> On 4/30/26 3:43 PM, Aaron Kling via B4 Relay wrote:
> > From: Teguh Sobirin <teguh@xxxxxxxx>
> >
> > This contains everything common between the AYN QCS8550 devices. It will
> > be included by device specific dts'.
> > [..]
> > +
> > +     /* The tzlog label is required by ABL to apply a dtbo, but it can be on any node */
> > +     qcom_tzlog: chosen {
> > [..]
> > +
> > +     /* The arch_timer label is unused here, but is required by ABL to apply a dtbo */
> > +     arch_timer: timer { };
>
> awkwaaard.. Is there any problem with requiring erased dtbo? For phones
> that's generally what's done. Having junk from random dtbos is best avoided.

This has been discussed like 6 times over at this point, like this [0]
thread for example. The request from there was to make this device
specific, so here it is. My use case needs a variant dtbo in order to
support all AYN qcs8550 devices in one software release. And the
install flow handles the dtbo partition, so for my use case there will
be no random junk. And use cases that don't want dtbo will instruct
users to erase the dtbo, and this doesn't prevent that.

> Also according to the pmOS wiki [1] at least on some of these devices,
> there's no need to boot from ABL at all! There's also U-Boot and you can
> switch between ABL and U-Boot at will (sounds awesome!)

My use case is Android, and shipping something installable by the
average Android custom rom user. Manually replacing bootloaders is not
something I want to force users to do. Especially given that the stock
bootloader supports all the android setup already, I don't want to
have to re-implement all that in u-boot. This has also been re-hashed
several times in series leading up to this.

> > [..]
> > +&i2c_hub_2 {
> > +     clock-frequency = <400000>;
> > +
> > +     status = "okay";
> > +
> > +     spk_amp_l: amplifier@34 {
> > +             compatible = "awinic,aw88166";
> > +             reg = <0x34>;
> > +             #sound-dai-cells = <0>;
> > +             reset-gpios = <&tlmm 103 GPIO_ACTIVE_LOW>;
> > +             awinic,audio-channel = <0>;
> > +             awinic,sync-flag;
> > +             sound-name-prefix = "SPK_L";
> I guess there's no real standard/convention for the prefixes but maybe
> worth changing to the more readable "Amplifier L" / "Amplifier R" that's
> used on e.g. the fairphone,fp5?

I guess I could.

> > +     };
> > +
> > +     spk_amp_r: amplifier@35 {
> > +             compatible = "awinic,aw88166";
> > +             reg = <0x35>;
> > +             #sound-dai-cells = <0>;
> Also #sound-dai-cells should go last, with a newline before it.

Ack.

> > +             reset-gpios = <&tlmm 100 GPIO_ACTIVE_LOW>;
> > +             awinic,audio-channel = <1>;
> > +             awinic,sync-flag;
> The awinic properties should also be a newline-separated "block", before
> the # one.

Ack.

> > +             sound-name-prefix = "SPK_R";
> > +     };
> > +};
> > [..]
>
> BTW, do these "just work" right now?

I get sound out of the speakers with no additional aw881166 driver
changes or manipulation on the amp alsa controls, so yes. I do have
instability with sound in general, like the active stream will
randomly stop making noise until a pause/resume or something in the
kernel (or adsp?) will start infinite looping, taking down the entire
card. But that appears to be related to the adsp or qcom dsp drivers
and how aosp interacts with them. Still playing whack a mole with
that.

Oh, and these devices also need mi2s clock support. Still waiting on
some version of that support to land. I will have to follow up with
whatever final form the dt plumbing for that ends up being, if any. I
do have to carry out of tree patches for this at the moment.

> If so, I guess you're lucky and the "firmware" / register config binary
> for these devices configures a 16-bit 48kHz format which is the one the
> soc driver forces.. because the aw88166 driver, just like other awinic
> amp drivers, doesn't negotiate the format stuff at all and blatantly
> lies about supporting multiple formats :) I'm currently fixing this for
> aw88261[2] but eventually we'll probably need to actually kinda unify
> these drivers..

I would assume that's what is happening. Having a more robust and
unified driver would be welcome, however.

Aaron

[0] https://lore.kernel.org/linux-arm-msm/20260207-sm8550-abl-dtbo-v2-1-83afaa6f3ce9@xxxxxxxxx/