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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
