Re: [alsa-devel] [PATCH 4/4] ASoC: DaVinci: pcm, fix underrun by using sram

On Wed, Jul 14, 2010 at 00:31:00, troy.kisky@boundarydevices.com wrote:

On Tue 13/07/10 6:00 AM , "Nori, Sekhar" nsekhar@ti.com 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