[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