[alsa-devel] ASoC - Support for multiple components
timur at freescale.com
Mon Apr 19 16:14:47 CEST 2010
Liam Girdwood 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.
I'll take a look at it this week or next.
> 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 ?
I've never looked at soc-of-simple before, so I can't say. Obviously, I've never needed it, and I never planned to use it.
> The code is in my topic/multi-component branch here :-
> It's currently a patch for each component for easier review atm but will
> be rebased into a single commit when it's ready for upstream so it won't
> break bisect.
> If the testing can be done quickly then we can go for 2-6.35 otherwise
> we are looking at 2.6.36.
Linux kernel developer at Freescale
More information about the Alsa-devel