Re: HDMI codec, way forward?

[Arnaud Pouliquen <arnaud.pouliquen@st.com>]

> After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
> audio was not discussed after all.
>
> My conclusion from the Lars-Peter's latest mail [2] related to the
> subject is that the wind is currently blowing slightly in favour of my
> version of the hdmi codec [3], or at least not in favour of Arnaud's
> version [4].
Based on previous discussions and lack of feedback from DRM community,
This make sens for me.

>
> So how should we proceed? Are we still waiting for some feedback from
> DRM/video side?
>
> There was not too many clear suggestions to my latest patch series
> [3], so I do not see too much point in sending yet another version of
> that series.
  For me, some points need to be clarified:
- Do we need the abort callback. Is there a uses cases that makes it 
mandatory (some timeout mechanism already exists to stop audio...)

- Does trigger is needed when CPU-DAI is master on bus?
Otherwise how to inform HDMI that I2S bus is no more clocked? I'm not
sure that mute is sufficient for all hardwares... For instance for my
hardware CTS parameter is hardware computed based on I2S L/R clock.

- IEC controls to support compress mode. This should be handled by codec 
driver in I2S mode, but not in SPDIF mode.

>
> Arnaud, if I'd try to make a patch series that would implement sti
> HDMI audio with my HDMI codec, would you be willing try that out?
hmm...more simple that i do the stuff for sti platform as some pieces of 
code are missing today in kernel (Device tree part).
I will try to find time next week to make a prototype for test and give 
you a feedback.

Additional point: We should also define some new helper functions:

- For N and CTS HDMI parameters: In my RFC i have proposed helper 
function, don't know if that matches with other platforms need...

- For IEC standard controls (could be added in core/pcm_iec958.c)

BR,
Arnaud