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?