Re: [PATCH v3 2/4] media: synopsys: hdmirx: add HDMI audio capture support

[Igor Paunovic]

Hi Dmitry,

That's really helpful, thank you. The get_eld() route makes sense --
reusing the ELD path to advertise the single wire rate (either by
generating an ELD in the driver or teaching the CODEC an explicit RX
rate restriction) is cleaner than what I had in mind, and having
userspace see exactly one capture rate and resample on its own side is
the right behavior.

I'll follow that flow -- plug event -> signal stable -> rate from ACR ->
register CODEC -> get_eld() -- when I get to the follow-up, and I'll run
the hdmi-codec side of it by the ASoC list since it extends the shared
CODEC driver. I'll keep you cc'd when I post it.

Thanks again for the pointer, and for the reviews and testing on this
series.

Igor

On Sat, Jul 25, 2026 at 7:58 PM Dmitry Osipenko
<dmitry.osipenko@xxxxxxxxxxxxx> wrote:
>
> Hi,
>
> On 7/24/26 02:47, Igor Paunovic wrote:
> > Hi Dmitry,
> >
> > Thank you -- and thank you for reviewing the whole series and testing
> > 2/4. It went through a lot of back-and-forth since the RFC, so having
> > it land with your Tested-by means a lot.
> >
> > I'll prepare the follow-ups as separate patches once this series is in:
> >
> > - The video_device lifetime issue on the V4L2 side (the devm-allocated
> >   struct with video_device_release_empty that the automated review
> >   flagged) -- as a standalone fix for the existing driver, since it's
> >   independent of the audio support.
> > - An atomicity fix for the GLOBAL_SWENABLE read-modify-write, now that
> >   the audio path adds a second writer to that register alongside the
> >   CEC code.
> >
> > The repeated-suspend wedge I mentioned in the cover letter I'd rather
> > send only once I have a clean, reproducible trigger for it -- it's
> > still under investigation and I don't want to send a fix ahead of a
> > solid repro.
> >
> > The dynamic codec registration you suggested (bind on the plug event,
> > read the actual wire sample rate and restrict the codec's rate) is the
> > direction I'd like to explore after these, once I've looked at what it
> > needs from hdmi_codec_ops.
>
> Good plan
>
> RE the sample rate restriction, hdmi_codec_ops has get_eld() that
> restricts rate based on HDMI ELD [1]. For RX we could tell the exact
> rate to CODEC without ELD or we could generate ELD in the driver, either
> way should require extension of CODEC driver with support of RX rate
> restriction. This way userspace will see that there is only one rate
> available for capture, so it won't be able to choose wrong rate and will
> resample audio itself as it needs.
>
> HDMI plug event -> signal stable -> gate audio rate from ACR -> register
> CODEC device -> ops.get_eld() returns our ELD
>
> [1]
> https://elixir.bootlin.com/linux/v7.1.3/source/sound/soc/codecs/hdmi-codec.c#L477
>
> --
> Best regards,
> Dmitry