[alsa-devel] [RFC 0/4] ASoC: Add HDA HDMI codec driver

[Vinod Koul]

On Fri, Oct 09, 2015 at 01:52:07PM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 09, 2015 at 01:28:45PM +0100, Vinod Koul wrote:
> > Yes, this patch series attempts to add yet another HDMI driver to
> > ASoC. This codec appears as HDA codec over HDA link. Although
> > the codec reside in display we have a HDA link from audio block
> > to this codec. The communication to codec is over HDA link
> > 
> > Thanks to i915 component infrastructure, we do not need to worry
> > about keeping the codec on, this is done by i915 for us.
> > 
> > Based on discussion with Mark here at ELCE and other attempts by
> > various folks on HDMI, I wanted to show on list the stuff we have
> > done and discuss and try to see how we converge various attempts
> > 
> > The driver here only supports stereo and doesn't do multichannel
> > just yet, will add later once we converge here. The support for
> > using i915 component notification by David will be added later
> > on.
> 
> I notice that you don't limit the capabilities of the ASoC device to
> the capabilities of the HDMI sink - is that an intentional design
> decision, or is it handled some other way?
> 
> I think that's the "interesting" part of HDMI - how should audio find
> out the capabilities on the HDMI sink, and that's the area which people
> have been struggling to design and come to some sort of concensus over.

I think we should set capabilities based on the sink capabilities. And these
should be set after reading the ELD. We want to do that when stream is
opened and we query ELD and set the constarinats based on ELD.
I have not added that code but this was the idea and was planned to come
after this

> I know HDA passes the ELD through hardware between the HDMI video and
> HDMI audio side, which hides some of this with the existing ALSA PCI
> HDA driver.

Yes that is true. But some times this is not quite reliable and getting
right ELD is little problematic resulting in breakages on HDA side.

So we have discussed this with Takashi and the general idea is that we add a
SW mechanism as well which will be based on i915 component framework to read
ELD reliably from display driver

I think as a general idea all the hdmi audio drivers should rely on component
interface generically to read ELD/ get notification (that was added
recently). Today on audio we have i915 component interface and IMHO this
should be made a generic audio-display component interface and used by all.
The callbacks are not really HDA based. But I don't really know on other
arch if that is doable or not...

-- 
~Vinod