[alsa-devel] [PATCH 08/11] ASoC: tegra: Add tegra-pcm driver

Stephen Warren swarren at nvidia.com
Wed Dec 22 20:03:29 CET 2010


Mark Brown wrote on Friday, December 17, 2010 3:07 PM:
> On Fri, Dec 17, 2010 at 02:41:27PM -0700, Stephen Warren wrote:
> > This provides an ASoC platform driver that manages Tegra's APB DMA
> > controller.
> 
> Oh, and one other thing: if your DMA controller has a free running mode
> it'd be much nicer to use that than to have to continually keep feeding
> it buffers.

As far as I can tell, Tegra's DMA controller doesn't provide a continuous
mode that's useful for audio.

The DMA controller does have a continuous mode, which can either
continually push the exact same buffer into the I2S FIFO, or can
continually push two contiguous same-sized buffers into the I2s FIFO. In
either case, I think we get an interrupt half-way through.

However, I don't see a way to handle a buffer with <n> chunks, and get an
interrupt for each chunk (unless n==2 of course).

I suppose we could use continuous mode if we set both periods_min/max==2,
but that seems a little inflexible.

Finally, for reasons I don't fully understand, even when the HW is in
continuous mode, the driver seems to require you to continually queue more
DMA requests into the driver's request list anyway, so tegra_pcm.c would be
doing just as much work, and hence is presumably no better for CPU usage
and power.

Perhaps this mechanism allows changing the buffer that continuous mode
operates on without shutting down the DMA engine, and hence allows emulation
of a larger buffer with interrupts on every chunk with more than two chunks.
Or, perhaps this is intended to allow SW to update the HW registers for the
next DMA half way through the current DMA, to avoid making the DMA engine
wait for the ISR to program the next operation during the ISR. Perhaps Colin
can comment more on this?

Given all that, I'm tempted to simply stick with single-shot mode for now.

-- 
nvpublic



More information about the Alsa-devel mailing list