[alsa-devel] Separate dma driver for cpu_dais

Joonyoung Shim jy0922.shim at samsung.com
Thu Feb 18 07:12:53 CET 2010


On 2/17/2010 7:52 PM, Mark Brown wrote:
> On Wed, Feb 17, 2010 at 03:58:15PM +0900, Joonyoung Shim wrote:
> 
>> At the ASoC, is there a situation to share the dai(cpu or codec)?
>> If the dai is shared, i just think the ASoC core cannot support it.
> 
> I'm not sure what you mean by "sharing" the DAI - sharing between what?
> I think you mean using the same DAI in multiple dai_links but I'm not
> 100% sure?
> 

Yes, it is what i mean.

>> There is the case at the S5PC1XX, it supports the hardware mixing by
>> using two tx fifo. First Jassi implemented codes using each other cpu
>> dai as Jassi says at the above for the hardware mixing, but it should
>> share codec_dai and need some modification of ASoC core.
> 
> What modifications are you looking for here?  ASoC doesn't make any

Thing modified is the active counting of DAI(struct snd_soc_dai) and pcm
stream(struct snd_soc_pcm_stream). Also, startup() in ops functions of 
same DAI shouldn't be called several times when the device using same 
DAI is opened.

> 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 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

Ah, i didn't think about this. Right, this should be considered too.

> 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.
> 

Sorry, what does "be open coded" mean?


More information about the Alsa-devel mailing list