On Wed, Jul 14, 2010 at 00:31:00, troy.kisky@xxxxxxxxxxxxxxxxxxx wrote:
>
> On Tue 13/07/10 6:00 AM , "Nori, Sekhar" nsekhar@xxxxxx sent:
>
> [...]
>
> > +static int request_ping_pong(struct snd_pcm_substream
> *substream,
> > + struct davinci_runtime_data *prtd,
> > + struct snd_dma_buffer *iram_dma)
> > +{
> > + dma_addr_t asp_src_ping;
> > + dma_addr_t asp_dst_ping;
> > + int link;
> > + struct davinci_pcm_dma_params *dma_data = prtd->params;
> > +
> > + /* Request ram master channel */
> > + link = prtd->ram_channel =
> edma_alloc_channel(EDMA_CHANNEL_ANY,
> > + davinci_pcm_dma_irq, substream,
> > + EVENTQ_1);
>
> What is the reason for choosing EVENTQ_1 for this channel?
> EVENTQ_0
> is already being used for ASP channel.
>
> I imagine it will be much easier to tune the queue usage in the
> system
> if all of audio data was using the same queue.
>
> I am working on a patch which lets platform specify the event
> queues
> for audio DMA. I am not sure if I really need to make a
> provision for
> two different queues to be specified - that's why I ask.
>
> Thanks,
> Sekhar
>
> The reason is so that the IRAM data can be fetched and used
> while
>
> EVENTQ_1 fetches the next buffer of data from sdram into IRAM.
Thanks for the explanation. That sounds reasonable.
Just curious as to whether you actually faced an issue
when using the same event queue for both transfers?
I just tested this on DM365 with both transfers on EDMAQ_0
with 16K each of capture and playback IRAM at 48KHz
sampling rate and did not find any issue.
Anyway it makes sense to make provision for platform to choose
different queues for both transfers so will implement my patch
that way.
Thanks,
Sekhar
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
