[alsa-devel] [RFC 0/5] ASoC multi-component support : core
mcuos.com at gmail.com
Sat Jun 26 04:25:50 CEST 2010
2010/6/25 Liam Girdwood <lrg at slimlogic.co.uk>:
> ASoC is now coming up to it's 5th birthday and is beginning to show it's
> age a little when it comes to supporting the next generation of smart
> phones and multimedia devices with it's current single CODEC and single
> DMA platform design.
> Historically, ASoC is designed around an embedded sound card with a
> single CODEC and a single platform DMA driver (with multiple DAIs). This
> design works great for most of the current audio hardware in production,
> however we are now seeing hardware designs for the next generation of
> devices that can have many CODECs, DMAs, DSPs and a host of other audio
> peripherals connected to the audio subsystem.
> So we now need ASoC to support new audio hardware architectures with
> multiple audio CODECs, DMA engines, DSPs, DAIs etc.
> This patch series allows an ASoC sound card to support multiple
> components (CODECs, DAI and DMA) and is the first part in a series of
> work (other parts coming later in the year from Mark and I) designed to
> enhance ASoC for modern mobile audio hardware.
> This patch series provides the following important features:-
> 1) Allow sound cards to have multiple CODECs and platform DMA controllers.
> 2) Allow CODEC drivers to support more than one CODEC device.
> 3) Allow all CODEC, platform DMA and DAI drivers to have platform data.
> This is achieved by: -
> 1) Separating the component struct driver data from the component struct device data.
> 2) Making all components kernel devices.
> (A side effect of this change is that we can now store all our component
> private data in struct device private data (like everyone else) and
> there is also now less pointer indirection for components.)
> The change mainly affects only the probe() and remove() sections of
> component drivers and the component enumeration section of the core. The
> core also now handles setting up the CODEC data structs too (meaning
> CODEC drivers dont have to do this). All component PCM, DAPM and
> Kcontrol operations remain unchanged.
> I've so far tested the new multi-component enumeration on the TI OMAP
> and Marvell PXA platforms with AC97, MFD and I2C based CODECs. I do
> however need ASoC platform maintainers to test on their systems (as I
> only have a subset of the hardware). Some ASOC platforms do need a
> little extra checking/fixups too :-
> o Samsung platform: required the most work to untangle the components.
> o i.MX platform: required work to de-couple components.
> o Injenic J4740 platform: I do not have a toolchain to even build this
> arch so it will also need someone to build it too.
> If you find your platform does not work then the most likely reason is
> that I'm missing a platform_device registration for your CODEC, DAI,
> etc. device in your arch board.c or device.c files. Please let me know
> or send a patch :)
> All the multi-component code is in my multi-component branch here :-
I really want to test my nuc900 platform, but the git tree seems to
where nuc900 most platform files not be merged. so I have to wait for
2.6.36 to update and test my driver?
> This RFC post contains the changes to ASoC core only. I'll post the
> multi-component CODEC and platform changes as separate RFCs in order not
> to flood the list (as there are 38 patches in all). This patch series
> will eventually be rebased into a single patch for upstream so we dont
> break bisect. The subsequent patches for CODECs and platforms in this
> series can be found in the git branch above.
> The intention is to upstream this for 2.6.36
> Freelance Developer, SlimLogic Ltd
> ASoC and Voltage Regulator Maintainer.
*linux-arm-kernel mailing list
mail addr:linux-arm-kernel at lists.infradead.org
you can subscribe by:
* linux-arm-NUC900 mailing list
mail addr:NUC900 at googlegroups.com
main web: https://groups.google.com/group/NUC900
you can subscribe it by sending me mail:
mcuos.com at gmail.com
More information about the Alsa-devel