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.