On Fri, Mar 01, 2013 at 09:42:10PM +0000, Liam Girdwood wrote: > On Fri, 2013-03-01 at 21:50 +0100, Lars-Peter Clausen wrote:
> > object. I mean the distinction is mostly for historic reasons from a time > > where > > it was only possible to bind a the cpu_dai of a link to a CPU DAI and the > > codec_dai to a CODEC DAI. But these dais both can for example be bound CODEC > > DAIs. I think to have a common base here would allow us to do some cleanups > > to > > the ASoC core and also avoid the duplication with > > snd_soc_of_get_cpu_dai_name > > and snd_soc_of_get_codec_dai_name which was introduced in this series. > I've been thinking about this distinction for some time too (since > multi-component support). You are right, the division with CODEC and CPU > DAIs is entirely historical. The same logic also applies to platform and > codec drivers too. The DAIs are now the same of course, it's just the containing object that differs. Platform drivers are a bit different to CODEC drivers for me though in that they encapsulate the DMA equivalent of a DAI - I can see a SoC having multiple platform drivers if it's got a couple of different DMA controllers for example (I've seen some which have a fancier one on faster buses for example). > This does need some mechanical cleanup where we have a generic audio > component driver object that contains generic DAIs. i.e. codec and > platform drivers would become generic component drivers with generic > DAIs. There's also the perennial questions about code churn and if it's worth it of course. Should we be adding a chip driver type rather than a CPU one here and then going through and doing the work to make sure that you can use a chip driver wherever you use a CODEC driver so we can start converting things over?
signature.asc
Description: Digital signature
_______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
