[alsa-devel] HDMI codec, way forward?

[Russell King - ARM Linux]

On Tue, Oct 20, 2015 at 09:08:09AM +0530, Vinod Koul wrote:
> On Mon, Oct 19, 2015 at 03:20:30PM +0200, Takashi Iwai wrote:
> > On Sun, 18 Oct 2015 19:16:42 +0200,
> > Russell King - ARM Linux wrote:
> > > 
> > > On Sun, Oct 18, 2015 at 09:43:29PM +0530, Vinod Koul wrote:
> > > > Right but can I ask why you didn't try making video as component and then
> > > > CEC, audio and others receive the notification over this.
> > > 
> > > Okay, I think I see what you're getting at.  No, I don't want to tie
> > > this stuff into the component helpers because that's the wrong approach.
> > > 
> > > The component helper is purely about combining several struct devices
> > > into one larger component for a subsystem which deals with card-level
> > > components.  It's not about cross-subsystem stuff.
> > > 
> > > The problem with using it for cross-subsystem stuff is that it becomes
> > > too tightly bound together: why should the graphics side get torn down
> > > if you unload the audio or CEC driver?
> > > 
> > > Audio and CEC are rather optional for HDMI - HDMI can work without audio
> > > and CEC being present.  However, audio can't be conveyed across the link
> > > without the video side being configured.  So, it makes sense to allow
> > > the CEC and audio parts to be loaded separately (possibly as modules)
> > > while having the video parts built-in to the kernel - especially if you
> > > want to use the HDMI output as the console.
> > > 
> > > Binding CEC and audio into the component helper alongside the video part
> > > will mean that nothing will come up until all the components are present,
> > > and everything will be torn down when any one of those components are
> > > removed.  Clearly, that's undesirable.
> > 
> > Currently i915/audio component works as you described.  The audio is
> > optional and HDMI graphics works without audio, while HDMI HD-audio
> > mandates i915 graphics.
> 
> Right, but we also add additional interface on top of this to allow things
> like ensuring display is on when audio wants to run and now notification for
> events.
> 
> I don't see a reason why this can be used as single interface to bind as well
> as talk to display from various components, unless I missed obvious which
> prevent us from doing this in non i915 cases...

Maybe I can comment more specifically if I saw the code.  Right now all
I'm aware of is this idea without any code, and I don't like it.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.