[alsa-devel] Separate dma driver for cpu_dais

Mark Brown broonie at opensource.wolfsonmicro.com
Wed Feb 17 14:14:22 CET 2010

On Wed, Feb 17, 2010 at 09:15:56PM +0900, jassi brar wrote:
> On Wed, Feb 17, 2010 at 7:52 PM, Mark Brown

> > What modifications are you looking for here?  ASoC doesn't make any
> > effort to avoid reuse of DAIs in multiple links - it doesn't actively do
> > anything to help here but equally well it's not supposed to get in the
> > way.

> The workaround to enable a cpu_dai to be used in multiple dai_links isn't

What workaround?

> going to work as such because of cpu_dai->runtime = runtime done
> in soc_pcm_open.
> Luckily for codec_dai, we can use the same in more than one dai_link.

Right, OK - CPU DAIs don't come up so much so I've not noticed that.

> > The only thing I can think of off the top of my head that would cause
> > actual problems is that the DAPM events for stream stop/start in the
> > CODEC might not be doing reference counting, I'd need to check.  Other
> > than that there's a bunch of things that could make use cases like this
> > nicer like providing a way of bundling links that share signals together
> > and providing callbacks when things start and stop (so shared clocking
> > can be turned on and off, for example) but these should be things that
> > could be open coded in individual drivers.

> Also, how cleanly could we avoid startup/shutdown/mute etc callbacks
> when a codec_dai is used in multiple dai_links, is to be seen.

The mute is just part of the reference counting I was mentioning, that's
fairly straightforward to resolve I'd expect.

Startup and shutdown will just work for a lot of drivers, either through
not having relevant callbacks in the first place or winding up being a
noop due to rewriting an identical configuration - as a first
approximation we can probably get away with open coding in any drivers
that do have a problem.

More information about the Alsa-devel mailing list