On Mon, Apr 19, 2010 at 8:09 AM, Liam Girdwood lrg@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.