[alsa-devel] channel swapping issue on OMAP3/TWL4030 is back

[Peter Ujfalusi]

On 03/22/2013 05:35 PM, Russell King - ARM Linux wrote:
> On Fri, Mar 22, 2013 at 02:04:42PM +0100, Peter Ujfalusi wrote:
>> Russell: can we remove the tasklet use from dma-omap and start the DMA right
>> away in omap_dma_issue_pending()? This is the only way to prevent channel
>> swap when starting audio.
> 
> What I fear is that we may run up against having too many DMA channels
> tied up to the peripherals.  I structured the driver in this way to
> allow us to move the physical DMA channel allocation to that tasklet
> when that becomes a problem.
> 
> Not only that but I was hoping to lift some more of this code out of
> DMA engine drivers, so DMA engine drivers had even less code in them.

Not sure what you mean by this. Move dmaengine core's issue_pending to a
tasklet or is only OMAP internal restructuring?

> I guess we could keep the tasklet, but mark the audio DMA channels as
> "pre-reserved" and arrange for pre-reserved channels to avoid the
> tasklet, rather than throwing the tasklet out completely.

Not sure if we really want to pre-reserve the DMA channels for audio:
on OMAP3 we have 5 McBSP -> 10 DMA channels
on OMAP4 we have 4 McBSP, one McPDM, one DMIC and one McASP + we have the
AESS/ABE -> 8 + 2 + 1 + 1 + 8 (AESS/ABE).
Do we really want to pre-allocate DMA channel for all of these?

We could look omap_chan.cyclic which gives good indication that the channel is
used for audio since only audio is using cyclic mode.

I have a patch which removes the tasklet from omap-dma.c and it is working
fine on my systems (OMAP3 Zoom2, BeagleBoard, OMAP4 PandBoard, OMAP4 Blaze).

I can modify it to not remove the taskelt, but when the omap_chan.cyclic is
true we would instead of starting the tasklet we just start the DMA right away.

-- 
Péter