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

From: Aaron Kling

Date: Thu Apr 02 2026 - 18:06:32 EST


On Mon, Mar 30, 2026 at 6:32 AM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Mar 30, 2026 at 01:00:55PM +0200, Konrad Dybcio wrote:
> > On 3/27/26 10:26 PM, Aaron Kling wrote:
> > > On Tue, Mar 24, 2026 at 7:36 AM Konrad Dybcio
> > > <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> > >>
> > >> On 3/23/26 5:27 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'.
> > >>>
> > >>> Signed-off-by: Teguh Sobirin <teguh@xxxxxxxx>
> > >>> Co-developed-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > >>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > >>> ---
> > >>
> > >> [...]
> > >>
> > >>> + sound {
> > >>> + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
> > >>> + pinctrl-0 = <&lpi_i2s3_active>;
> > >>> + pinctrl-names = "default";
> > >>> +
> > >>> + model = "AYN-Odin2";
> > >>
> > >> Is this enough of a distinction? Do you need to make any changes to the
> > >> one with a HDMI bridge to get HDMI audio?
> > >
> > > After this quesstion, I tried to verify hdmi and am unable to even get
> > > the connector to come up. The lt8912b driver complains that the
> > > connector doesn't support edid read.
>
> Looking at the driver, please drop lt8912_bridge_edid_read(),
> lt8912_bridge_detect() and lt->bridge.ops assignment. Those bits are
> lame and useless.
>
> > Which per the current connector
> > > node is correct, none of the devices list a ddc node. I am trying to
> > > investigate this further, but vendor source release unfortunately
> > > appears to be missing pieces related to this. And no other current
> > > qcom device uses this bridge to take a guess at which controller the
> > > ddc is on.
> >
> > Go through the I2C buses that are enabled on the vendor kernel and try
> > inspecting them with toos like i2cdetect
>
> I'd second this suggestion. The chip doesn't support EDID reading, so it
> is (hopefully) handled via some existing bus. Does downstream handle
> EDID / HDMI at all?

I have been unable to get the stock OS to display anything on hdmi at
all. The downstream kernel reports the head as DSI, and is hardcoded
to a 1920x1080 mode in the kernel dt. We have been unable to find any
kernel handling of this bridge at all for downstream, in the source
release or the prebuilt kernel shipped with the stock OS. Best I can
tell, they just hardcode the one mode and nothing else will work.
There are reports of hdmi audio working, though; which I'm not sure
how if the bridge has no kernel driver at all.

All i2c nodes used by downstream are already enabled. And when an hdmi
cable is plugged in, I never see the ddc address, 0x50 if I understand
correctly, show up on any of them. I tried enabling other i2c nodes to
check if anything shows up on them, but that causes kernel panics
during boot and without uart, I can't see why.

This all seems rather broken, perhaps by odm design. Given this state,
should I just drop all references to hdmi and leave a comment in the
dts where the bridge should be to explain why?

> >
> > >
> > > On a related note, I'm not sure hdmi is covered in the audio topology.
> >
> > Since this is a DSI bridge, I'd imagine it needs a separate connection
> > to the SoC's sound hardware. We've had similar occurences in the past,
> > e.g. this on the SM8250 RB5 board (qrb5165-rb5.dts):
>
> Yes. Unfortunately, the driver doesn't seem to implement audio support.
> I'd suggest pinging Lontium for the information regarding InfoFrame and
> audio bits programming.
>
> >
> > https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/Qualcomm/sm8250/HDMI.conf
> >
> > Maybe +Dmitry could help you out
> >
> > Konrad
> >
> > > What I'm using is here [0]. This is in a fork of the topology repo
> > > with aosp build rules added. Speakers work, headphones out and in
> > > work. DP works only with the pending q6dsp fixups series, which I
> > > should probably narrow down and ask for a 6.18 backport for. The ucm
> > > config [1] I'm basing tests on doesn't handle the built-in mic and I
> > > haven't been able to figure that out yet, so that's also unknown.
> > >
> > > Aaron
> > >
> > > [0] https://github.com/LineageOS/android_hardware_qcom_audioreach-topology/blob/ad67f3777b1d4dec5289bc7117f2ec34521be7e6/AYN-Odin2.m4
> > > [1] https://github.com/AYNTechnologies/alsa-ucm-conf/commit/d33738b93e9560e8d9e08a024cc84c8055bb7eb9
>
> --
> With best wishes
> Dmitry

Aaron