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
