Is something using DMA channel 0?

Philip Ashmore contact at
Thu Nov 7 21:14:52 EST 2013

On 07/11/13 08:03, Richard Hirst wrote:
> Servoblaster uses DMA channel 0 from user space too, by directly
> accessing registers through /dev/mem.  That is quite widely used and I
> haven't heard of any issues with it.  That code to turn the Pi in to an
> FM radio transmitter did it too.  I'm not trying to suggest it is a good
> approach, but it seems to work in many cases.  I did have to jump
> through a few hoops to work round caching issues, see servod.c in the
> servoblaster repository on github. 
I saw "these are L1 & L2 non-coherent cached pages" - huh?
Can you refer me to documentation for this as it doesn't make sense to me.

As far as I can tell, any maps onto the I/O don't have this problem, do
> Richard
> On 7 Nov 2013 07:18, "Craig McGeachie" <slapdau at
> <mailto:slapdau at>> 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.
>     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
>     <> would have been a better place.
>     Cheers,
>     Craig.
>     _________________________________________________
>     linux-rpi-kernel mailing list
>     linux-rpi-kernel at
>     <mailto:linux-rpi-kernel at>
>     <>

More information about the linux-rpi-kernel mailing list