[alsa-devel] [PATCH 0/2][RFC] snd_soc_codec include snd_soc_component

Kuninori Morimoto kuninori.morimoto.gx at renesas.com
Mon Sep 2 10:52:27 CEST 2013

Hi Lars

Thank you for your feedback

> > But, we will need many "codec dai name exchange", becouse
> >  1) the dai name rule on 1-dai / multi-dai are different,
> >     it was depend on snd_soc_register_dai[s].
> >  1) component is using both snd_soc_register_dai[s] inside
> >     (this was for "cpu" side limit)
> >  2) codec have been used snd_soc_register_dais even though
> >     it was not multi-dai
> > 
> We only added the distinction between components with one DAIs and multiple
> DAIs since most of the CPU DAI drivers with only one DAI used
> snd_soc_register_dai() and we wanted to avoid having to update all the DAI
> links. How about adding a boolean flag to __snd_soc_register_component()
> which if set causes the function to always use snd_soc_register_dais(). This
> will allow us to keep the existing naming for CODEC dai.

It is easy hack.
OK, we can try it.

> > 2nd patch is rough version of "code dai name exchange" for it.
> > Of course we need more and more codec driver patches,
> > but it is wm8978 only as trial now.
> > 
> > I guess "codec driver" should have "component driver" pointer too ?
> > (it has .name only at this point, and 2nd patch includes it)
> In my opinion it is better to embed the component_driver struct into the
> codec_driver struct just like the component struct is embedded in the codec
> struct. Otherwise your patch looks fine to me. Maybe move

I see.

> __snd_soc_register_component() up, so the forward declaration is not needed
> anymore.

This was the reason why I used "rough" naming here :P

> > We can move some feature from codec to component
> > after this step ?
> > 
> Yes. I think most of the fields managed by the core which are not touched by
> any drivers can be moved easily.

Nice !

As my previous email said, this patch cares only codec <-> component,
but we re-consider about "component"
if component will be used from "platform" (and "card" too ?) ?
(since it is controlling "dai" inside)
Or is it 2nd step like above ?

I can say current style is quick-hack, but it is easy to go to next step.
I'm not sure this is good plan

Best regards
Kuninori Morimoto

More information about the Alsa-devel mailing list