[alsa-devel] ASoC - Support for multiple components

[Grant Likely]

On Mon, Apr 19, 2010 at 8:09 AM, Liam Girdwood <lrg at slimlogic.co.uk> wrote:
> Currently ASoC is designed around a single CODEC and a single platform
> DMA engine in every sound card instance. This is fine for most embedded
> devices but current smart phone and STB designs are starting to outgrow
> this architecture.
>
> I'm currently working on adding ASoC support for multiple different
> CODECs and Platforms (DMA, Audio Engines) into a single sound card
> instance. This work will allow ASoC to support N CODECs and N platforms
> per sound card instance and also allow better integration of audio
> components from GSM MODEMs, BT, FM transceivers and PCM DSPs.
>
> I've now split each ASoC component (i.e. DMA, CODEC, DAI) into driver
> and device structures. This now means each ASoC component is a regular
> kernel device and can have private device data and platform_data. It
> should also provide better support for open firmware and flattened
> device tree.
>
> I've CC'ed folks on this mail who have either contributed or maintain
> ASoC architecture code. Please have a look at your architecture and test
> if you can. I only have access to OMAP and pxa3xx hardware and as such
> have only tested the changes on these two architectures only. I'd
> appreciated anyone else testing on the other architectures too.
>
> The changes are all purely mechanical to component registration and
> component private data only. However, some architectures (txx9, imx,
> s3c) required some extra effort to use the device model as they had (to
> varying degrees) coupled their DMA and DAI code more tightly. The fsl
> platform also required extra work around the open firmware interface.
> Grant/Timur do we still need soc-of-simple now that all components are
> regular devices ?
>
> The code is in my topic/multi-component branch here :-
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git

Hi Liam,

This is definitely a step in the right direction.  All of the OF ASoC
stuff is definitely a hack to work around the lack of separate devices
& drivers in the ASoC subsystem.  I'll take a look through, but some
more information would help a lot.  Can you write a description of the
device model that you're using for the ASoC linkage?  Here are some of
the questions I have:

- What bus type is used for codec and platform (dai) device
registrations?  (okay, 'platform' is really confusing here because of
the dual meaning with Linux driver core.  I'm going to use 'dai' in
this email instead from now on.  It might not be the best term, but it
at least it isn't ambiguous.)
- What does the device hierarchy look like (what is the parent device
for each of the codec and devices)?
- Related to that, how are things like i2c codecs handled?  By rights,
there will be an i2c device registered under the i2c bus device for
the control interface.  How will this relate to the ASoC model?
- None of the drivers appear to include struct device_driver; which
tells me that they don't use the driver core binding model.  How do
drivers get bound to devices?  Why does the ASoC code create an driver
interface instead of using the core code (what does the core code not
provide)?
- What code is responsible for performing the codec and dai driver
registrations?

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.