Re: [PATCH v2] drm/display: let a bridge configure sink audio from hw_params

[Jean-Francois Bobier]

On Mon, Oct 05, 2026 at 06:18:24PM +0200, Jean-Francois Bobier wrote:
[...]

> Similar changes were proposed several times already. The IEC958 status
> bits are usually set by the userspace after the .hw_params callback has
> been called. With your approach the hardware will never receive correct
> status bits.

That's a real concern in general, but I don't think it applies to the
case this patch is actually fixing. hdmi_codec_iec958_default_put()
is optional -- hcp->iec_status already has a sane default from
snd_pcm_create_iec958_consumer_default() at init, and both
hdmi_codec_hw_params() and hdmi_codec_prepare() fill it from that same
baseline. Userspace only needs to override it for passthrough of
compressed formats, where IEC958_AES0_NONAUDIO has to be set correctly
before the stream opens.

For ordinary PCM playback -- which is the only thing DP/HDMI audio on
this board does -- nothing in the userspace stack ever touches that
control. I checked our actual UCM profile rather than assume: the HDMI
device there is a plain mixer enable and PlaybackChannels 2, nothing
IEC958-related. So the ordering you're describing matters for
passthrough users, but doesn't affect the case I have hardware for.

> If my understanding is correct, a more apropriate fix is to make the
> a6afe driver to emit AFE enables at the .trigger point instead (maybe
> together with other commands) or to split the DP audio init, moving the
> necessary bits from the dp_audio_prepare to the dp_audio_startup
> callback.

I looked at q6afe-dai.c before replying. It doesn't implement .trigger
at all today, for any of its port types -- HDMI/DP, SLIMBUS, MI2S, TDM,
WSA codec DMA, USB all go through the same q6afe_dai_prepare(). Adding
.trigger there to fix DP timing would change behavior for every one of
those, on hardware I have no way to test.

The startup/prepare split is narrower, but I don't think it's free
either: .startup/.shutdown are tied to device open/close, not to each
hw_params/prepare cycle, so I'm not sure it actually survives a
suspend/resume any better than what this patch does -- it may just
relocate the same question rather than close it. Possibly worth
someone who knows this driver better confirming either way.

Given that, I'd rather not drop this while something that actually
works waits on a rewrite of a shared CPU DAI driver that doesn't exist
yet. Happy to be told I'm wrong about either of the above if I'm
missing something.

> Please take a look at Documentation/process/submitting-patches.rst and
> likely Documentation/process/coding-assistants.rst. For example, don't
> send the new version of the patch as a response to the previous
> revision.

Noted on the threading -- that's on me, I'll send revisions as fresh
threads with a link to the prior version instead. I'm not used to 
mail-based workflows like this in my work :(

Please let me know what you think - the patch does work on my board and 
brought up DP audio 100% working, but I would understand if it's not 
worth upstreaming given architectural impacts. (The bot seems to have 
found other gotchas on my v2 patch already so I will hold off until it's 
confirmed it's worth upstreaming at all).

Jean-Francois