On Wed, Oct 07, 2026 at 10:46:06AM +0200, Jean-Francois Bobier wrote: > 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.
That's the difference between the framework and a single driver. At a framework level we'd like to ensure that it doesn't let wrong values to be programmed and transmitted to the receiver. Moreover, I don't think there is anything preventing AC3 passthrough from working on Qualcomm hardware (and then it becomes an issue). > > > 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. Srinivas, would you have any suggestions or recommendation? > > 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 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). I think the issue is worth tracking and fixing, but at a different place. I've pinged my colleague, let's see if he will have any detailed suggestions. -- With best wishes Dmitry
