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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
