HDMI codec, way forward?

[Jyri Sarha]

On 10/16/15 16:51, Arnaud Pouliquen wrote:
>> 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...)
>

I am not currently using the abort_cb my self, so it can be dropped as 
well. Is should not be needed for codec DAI implementations, as long as 
the CPU-DAI is the i2s master.

> - 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.
>

The most of the codec drivers do not implement the trigger callback as 
the stream start and stop timing is usually handled at the CPU-DAI. 
Codec is just prepared (quite often even without prepare callback) and 
the stream start/stop is triggered at CPU DAI end. However, I should 
probably still implement the trigger callback and let the video side 
driver decide if it needs it or not.

> - 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.
>

That would be even better. Just let me know I can help you in any way.

> 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...
>

Absolutely, but I don't think these helpers should have any direct 
association to ASoC side. So they are in a way orthogonal to the ASoC 
side HDMI codec implementation. But very relevant to the video side 
driver registering the HDMI codec.

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

Oh, I did not even realize that there are predefined special kcontrols 
for handling the status bits. Adding those sounds like right thing to do.

Cheers,
Jyr