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

[Peter Ujfalusi]

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...

-- 
Péter