Is something using DMA channel 0?

[Craig McGeachie]

On 11/07/2013 05:57 PM, Philip Ashmore wrote:
> Hi there.
>
> Please forgive me in advance if I'm posting this question on the wrong list.
>
> I wrote a C++ library to control the Bcm2835 from user space:
> v3c-raspi: http://sourceforge.net/projects/v3craspi/
>
> But it appears that something writes to the DMA channel 0 control
> register at random intervals - I managed to get the i2s example running
> for 5 seconds before the problem occurred. Other times it happens almost
> immediately.
>
> I posted this bug originally:
>
> Is something using dma channel 0?
> https://bugs.launchpad.net/raspbian/+bug/1231791
>
> Then I found someone else who wanted to do something like it:
>
> How fast is GPIO+DMA? Multi I2S input
> http://raspberrypi.stackexchange.com/questions/9646/how-fast-is-gpiodma-multi-i2s-input/10287#10287
>
> But no responses to either regarding my issue.

You don't say which version of the kernel you're using for the Raspberry 
Pi, so I assume that most likely you're using whatever comes with the 
distribution which will be sourced from the 3.6 branch of 
https://github.com/raspberrypi/linux.

This being the case, then typically the framebuffer driver will use 
DMA#0. It's the only channel available for use by the ARM that has an 
external 8 entry FIFO attached to it, so it's the most efficient for 
memory to memory block copy, which the framebuffer uses for its copyarea 
implementation, if it can.  I imagine this function would be invoked 
every time the console shifts up for a new line.  Or for any sort of 
bulk rectangle move in X11.

I had a quick look at some of your code.  You're manipulating IO memory 
directly through /dev/mem, so you'll be bypassing the arbitration 
mechanisms in arch/arm/mach-bcm2708/dma.c.  If you are interfering with 
DMA#0 when the kernel doesn't expect you to be, then I'm a little 
surprised you don't see a bit of corruption on the console display.

You mentioned elsewhere about setting dma.dmachans in cmdline.txt. 
While this might stop dma.c from allocating DMA#0 if it were passed 
through, I would doubt that it was passed through to the kernel by the 
videocore bootloader.  cat /proc/cmdline and check the output.  If your 
value for dma.dmachans is there, look for a second value that the 
bootloader added.  See if your value was just replaced (n.b. I'm too 
lazy to actually try this myself and see what happens).

If your value is the only one displayed in /proc/cmdline, then I really 
have no idea what's happening.

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.

> Is this the right place to post this question?

I really couldn't say. Despite you getting a, hopefully, helpful answer 
here, I would have thought that http://www.raspberrypi.org/forum would 
have been a better place.

Cheers,
Craig.