All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Girdwood <lrg@slimlogic.co.uk>
To: alsa-devel <alsa-devel@alsa-project.org>
Cc: vbarinov <vbarinov@embeddedalley.com>,
	Cliff Cai <cliff.cai@analog.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	mano@roarinelk.homelinux.net,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	"Candelaria Villareal, Jorge" <jorge.candelaria@ti.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	dg@emlix.com, Grant Likely <grant.likely@secretlab.ca>,
	Sedji Gaouaou <sedji.gaouaou@atmel.com>,
	"kyungmin.park" <kyungmin.park@samsung.com>,
	ben-linux <ben-linux@fluff.org>,
	Kuninori Morimoto <morimoto.kuninori@renesas.com>,
	Timur Tabi <timur@freescale.com>,
	anemo@mba.ocn.ne.jp, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: ASoC - Support for multiple components
Date: Mon, 19 Apr 2010 15:09:04 +0100	[thread overview]
Message-ID: <1271686144.3208.305.camel@odin> (raw)

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

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.

Thanks

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

             reply	other threads:[~2010-04-19 14:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 14:09 Liam Girdwood [this message]
2010-04-19 14:14 ` ASoC - Support for multiple components Timur Tabi
2010-04-19 15:15 ` Grant Likely
2010-04-19 16:25   ` Liam Girdwood
2010-04-19 17:14     ` Mark Brown
2010-04-19 17:23       ` Liam Girdwood
2010-04-19 17:03   ` Mark Brown
2010-04-20  7:17 ` Peter Ujfalusi
2010-04-20 10:46   ` Liam Girdwood
2010-04-21  5:53     ` Peter Ujfalusi
2010-04-21  7:18       ` Liam Girdwood
2010-04-21 17:41         ` Mark Brown
2010-04-26 10:49     ` Mark Brown
2010-04-26 11:17       ` Liam Girdwood
2010-04-26 14:24         ` Mark Brown
2010-04-26 12:05       ` Timur Tabi
2010-04-26 13:13         ` Mark Brown
2010-04-21 21:07 ` Timur Tabi
2010-04-21 22:13   ` Timur Tabi
2010-04-22 11:27     ` Liam Girdwood
2010-04-22 14:52       ` Timur Tabi
2010-04-22 11:03   ` Liam Girdwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1271686144.3208.305.camel@odin \
    --to=lrg@slimlogic.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=ben-linux@fluff.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=cliff.cai@analog.com \
    --cc=dg@emlix.com \
    --cc=grant.likely@secretlab.ca \
    --cc=haojian.zhuang@gmail.com \
    --cc=jorge.candelaria@ti.com \
    --cc=jy0922.shim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=mano@roarinelk.homelinux.net \
    --cc=morimoto.kuninori@renesas.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sedji.gaouaou@atmel.com \
    --cc=timur@freescale.com \
    --cc=vbarinov@embeddedalley.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.