Assigning or reserving DMA controller channels

Is there a system for assigning or reserving DMA controller channels in the OMAP? I see it’s got 32 channels, and my chances of picking one that’s not already in use are high – perhaps even 100%! – but it shouldn’t be left to chance. Has RISC OS’s resource reservation system been extended to the OMAP’s DMA controllers? Or is there another system?

I have to use DMA for the SD/MMC controller; there is no other way to access the data.

Whatever the system is, it has to work very early on in the boot process, if it’s going to help during reading the “CMOS RAM” equivalent file for the first time at boot-up.

OK, please ignore this request – I see that I can do PIO after all. For the amount of data I’m dealing with, PIO will be just as fast, and a whole lot easier to set up.

OK, please ignore this request

Request denied!

At the moment, the SDMA channels are split between two software components. 31 of the channels are owned by the DMAManager module. This allows clients (e.g. SoundDMA) to claim channels and schedule transfers on them. The remaining channel not owned by DMAManager is used directly by OMAPVideo, since OMAPVideo needs to use some of the advanced features which currently aren’t supported by DMAManager (rectangle copies & fills).

So in your case, you’d want to use DMA_RegisterChannel to get your hands on a channel, then use DMA_QueueTransfer to schedule transfers. And in relation to your other thread – one of the good things about DMAManager is that it handles logical → physical address translation for you, along with splitting the transfer into smaller chunks should the transfer cross a page boundary, and pausing and resuming the transfer should RISC OS decide to remap the physical pages that you’re using. It also handles CPU cache synchronisation.

Unfortunately, writing about this has reminded me that the current version of DMAManager isn’t very well documented. If you wanted to use it now you’d have to combine together the documentation that’s in PRM 5a, the DMAManager Doc folder, and the notes in the OMAP3 driver (specifically, the fact that the “logical channel” which you pass in R1 to DMA_RegisterChannel should in fact be the value that you want programming into the DMA4_CCRi register). Plus you need to be aware that the audio driver (the only thing that’s using DMAManager on OMAP at the moment). If I get some time over the next week or two I might try wikifying the relevant docs.

Something else to be wary of is the nasty hack which the audio code uses – the McBSP module (which receives the data from the DMA controller) receives data in fixed-size packets. This means that both the DMA controller and the McBSP module need to be programmed with identical packet sizes, something which can’t be accounted for with the current RISC OS APIs. So once the HAL audio driver determines which packet size to use it stores it in a section of HAL workspace, which is then read back by the HAL DMA driver before setting up each transfer. So if the SD/MMC controller needs data to be sent in fixed-size packets then a similar hack (or preferably, a proper API extension!) will be needed.