Re: [PATCH 0/2][RFC] snd_soc_codec include snd_soc_component

[Lars-Peter Clausen <lars@metafoo.de>]

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
>> 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 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.

- Lars