Re: [PATCH 1/5 v7][RFC] ASoC: add snd_soc_register_cpu()

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1773 bytes --]

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?

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]