Is something using DMA channel 0?

[Craig McGeachie]

On 11/08/2013 09:43 AM, Philip Ashmore wrote:
> On 07/11/13 07:17, Craig McGeachie wrote:
>> Incidentally, you mention passing 0x7ffe as the channel mask.  I suspect
>> that this is not safe.  The typical value I see is 0x7f35 meaning that
>> the videocore has reserved channels 1, 3, 6, 7, and 15 for itself.  You
>> probably don't want to tell ARM core code that it can use these
>> channels.  That said, I think most of the time it won't be an issue.
>> Kernel code makes very little use of the DMA channels.
> So shouldn't the videocore bootloader do an AND with the bits it
> reserves or is that too sensible?

I don't think the videocore should do a bitwise and.  Obviously I didn't 
write the videocore bootloader, so I'm making a pretty wild guess here. 
  I think it was only meant as a quick and dirty mechanism to 
co-ordinate DMA channel usage between code running on the two different 
cores.  I don't think whoever wrote the code intended to support a 
general mechanism for configuring channels to not be managed by kernel 
code.  If I was writing videocore code, I don't think I'd be interested 
in parsing a hexadecimal number, and modifying it, rather than just 
doing a nice simple format as string and write to memory.

Any code running on the same core should be able to do its own 
co-ordination.  I reckon it wouldn't be too hard to write a kernel 
driver that exposed the DMA channel reservation and allocation mechanism 
to some sort of user space API.  ioctrl or mmap on a device file maybe. 
  A sysfs handler perhaps.

There is another mechanism for ARM code to find out which DMA channels 
the videocore has permitted the ARM to use - an interprocessor call API 
from the ARM to videocore [1].  If kernel DMA code were written to use 
this, then you would have to re-write kernel code to intercept and 
change the value, and the dma.dmachans kernel command line option would 
have no effect at all.

Please don't ask why the DMA driver wasn't written to use the mailbox 
call in the first place rather than introducing a command line option. 
I don't know, and it makes no sense to me.

It's also occurred to me to ask, if 0 is problematic, why don't you 
simply try using another channel?  I think 4 or 5 ought to be good.

Cheers,
Craig.

[1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface