Date:	Fri, 14 May 2010 01:29:56 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Brian Swetland <swetland@...gle.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <gregkh@...e.de>,
	Daniel Walker <dwalker@...o99.com>,
	Matthew Garrett <mjg@...hat.com>,
	Paul Walmsley <paul@...an.com>,
	Arve Hj?nnev?g <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Alan Stern <stern@...land.harvard.edu>, magnus.damm@...il.com,
	Theodore Ts'o <tytso@....edu>,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>,
	Beno?t Cousson <b-cousson@...com>, linux-omap@...r.kernel.org,
	Vitaly Wool <vitalywool@...il.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

On Thu, May 13, 2010 at 04:48:40PM -0700, Brian Swetland wrote:
> On Thu, May 13, 2010 at 4:36 PM, Mark Brown

> Current published trees are based on .32 (used for the coming-soon
> froyo release that's been in late QA for a while now) and forward
> development is moving to .34 post final (or in the case of tegra2,
> tracking .34-rc series as it happens).  We've been actively snapping
> up to track mainline since we started doing this around 2.6.16.  We'd

Yeah, I had noticed the development stuff was more up to date - it'll be
good once it gets out of QA and into general use since system
integrators do seem to pick up your new releases fairly quickly.

> *love* to be able to get more stuff sanely upstream instead of
> maintaining branches and rebasing every other mainline release or so.

Having greatly cut down the number of out of tree drivers I'm carrying I
can only say that it's great when it happens :)

> I'd love to have a separate discussion on using standard linux
> embedded audio for mobile devices -- one of my goals for 2010 is to
> try to migrate from our "one off" approach on MSM to making use of

Probably best to do that, this thread is already quite big enough
without going off on a tangent.  FWIW we can usually be found in
#alsa-soc on freenode as well as on the lists.  A couple of pointers
which might help your research, though:

> ALSA and standard interfaces.  I have a lot of questions about handing
> encoded data (mp3/aac/etc) that will be processed by the DSP, how to

This usually doesn't go through ALSA at all (the ALSA APIs can't cope
with variable bitrate data), the data currently goes via DSP specific
APIs and gets injected into the ALSA domain in much the same way as data
from the baseband.

> approach routing control, and how to best interact with the
> user/kernel interface, etc.

Routing control for embedded systems is done by exposing the routing
control to userspace via ALSA controls which can be set by apps - using
a GUI to configure the routes interactively is a massive usability win
in development.  Abstraction for generic user-visible apps is intended
to be handled by a layer on top of that:

	http://www.slimlogic.co.uk/?p=40

which is currently in development but I believe is expected to come to
fruition this year (Liam is driving this one).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists