[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