Is something using DMA channel 0?

Philip Ashmore contact at
Thu Nov 7 15:43:29 EST 2013

On 07/11/13 07:17, Craig McGeachie wrote:
> 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:
>> 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?
>> Then I found someone else who wanted to do something like it:
>> How fast is GPIO+DMA? Multi I2S input
>> 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
> 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.
Two things:
1. I'm providing the channel mask to stop the kernel etc from using DMA
channel 0 which is my way of saying "operator reserved - don't you use
it, kernel buddy".
2. This is intended to be a battery operated device, no display.
   I do all testing via wifi/ssh, a breadboard and some leds to show
that some pins are "doing something".

I use a bus pirate for more detailed GPIO analysis, which can capture up
to 4M samples/sec digital samples on a couple of leads.
> 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.
So shouldn't the videocore bootloader do an AND with the bits it
reserves or is that too sensible?
>> 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 would
> have been a better place.
That changed to apparently.
It would be great if there were an authoritative reference for this, and
yes you're right that should be somewhere on the Raspbian web site.

I just looked there in case things changed.
They haven't - they still have a link to the "linux raspberry pi kernel
mailing list" - this list.
> Cheers,
> Craig.
Thanks anyway, I hope someone's in the mood to be "authoritative"!

Philip Ashmore

More information about the linux-rpi-kernel mailing list