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