[alsa-devel] HDMI codec, way forward?

[Takashi Iwai]

On Wed, 21 Oct 2015 19:34:37 +0200,
Russell King - ARM Linux wrote:
> 
> On Wed, Oct 21, 2015 at 09:49:28PM +0530, Vinod Koul wrote:
> > On Wed, Oct 21, 2015 at 03:37:47PM +0100, Russell King - ARM Linux wrote:
> > > In any case, this doesn't (and can't) solve the CEC problem, so it's not
> > > a solution to the problem at hand.
> > 
> > Sorry am not sure I follow the reasons for that, wouldn't CEC be another
> > slave in such an interface? I though component fwk did allow us to have
> > multiple slaves..
> 
> Not with the way you're using the component helper here.
> 
> I guess that not all my message is being read, because people keep
> replying half-way down my messages...
> 
> You can only register a struct device _once_ as a slave device.
> 
> With the way you're using it here for audio, you're registering the
> i915 DRM device as a slave component device, and the audio side as
> the master.  That means the audio master can bind to the DRM slave
> component device.
> 
> You can't then have a CEC master bind to the i915 DRM slave device
> (it's already bound to the audio master device), and you can't
> register the i915 DRM device as a second slave component device.
> It becomes indistinguishable from the first, and there's no way
> to tell which of the two different 'ops' structures should be used
> with which master.
> 
> I said this in my message 20151021140307.GE32532 at n2100.arm.linux.org.uk
> which was two of my replies ago in this sub-thread.

Can't the limitation of single slave dev be extended simply?  e.g. add
some matching semantics to component_master_add_child() like a shared
key in both master and slave, and let assign only the matched slave.

I might think of the problem too easy, but didn't see any obvious
restriction in the code except for that...


thanks,

Takashi