[alsa-devel] [PATCH 0/2][RFC] snd_soc_codec include snd_soc_component
lars at metafoo.de
Mon Sep 2 11:34:15 CEST 2013
On 09/02/2013 10:52 AM, Kuninori Morimoto wrote:
> 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
> 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 think it can be done as a second step, as long as we keep in mind that we
want to do this eventually and don't built up any road blocks that will
prevent us form doing so.
More information about the Alsa-devel