On 03/25/2013 06:15 PM, Russell King - ARM Linux wrote:
What I'm talking about is having a physical channel scheduler in place across DMA engines which have more virtual channels than physical channels. Some DMA engine implementations sort of do this already (eg, AMBA PL08x stuff) but again, every driver implements this kind of thing by themselves.
I see. So basically you want to grab a DMA channel for the upcoming transfer at issue_pending time. This is fine, but we do not need to have taskelt to do this. If we do it as the amba-pl08x.c does it it is fine. AMBA does not use tasklet and OMAP should not do that either. We might need to lift the code out from the legacy DMA code (and remove the code) from arch/arm/plat-omap/dma.c...
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?
Well, at the moment we are effectively pre-allocating a physical channel for every virtual channel - as each virtual channel gets allocated. So, the physical channels are currently being permanently tied up.
With a scheduling core, we need some way to dynamically reallocate physical channels depending on the workload presented on the virtual channels. However, as we're still having to deal with the OMAP private DMA API, we can only change physical channels from task (or tasklet) context.
So, the only way to have audio channels in a condition where they can be startable immediately in issue_pending is to avoid the tasklet, and the only way to avoid that tasklet (where that tasklet eventually becomes the channel scheduler) is to have pre-allocated the physical channel.
The issue has been noticed in audio but it can also affect other drivers as well. It might be only latency/throughput issue for others, while audio suffer with the tasklet based DMA start.
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'm sure you have, but that breaks the future direction of the driver to dynamically allocate the physical channels.
Had TI not effectively terminated my contract, I might be further forward with this. As things are, lack of contract and such like, all the OMAP work I was doing got shelved around Christmas time. If you stop paying people, they generally stop doing useful work for you...
Yeah, that is bad. If it makes you feel a bit better just look up in google: "Texas Instruments France" Hint: I'm in France...