Is something using DMA channel 0?
contact at philipashmore.com
Thu Nov 7 15:51:49 EST 2013
is the page that has a link to this list.
On 07/11/13 20:43, Philip Ashmore wrote:
> 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
>>> 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
>>> 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 http://www.raspberrypi.org/forum would
>> have been a better place.
> That changed to http://www.raspberrypi.org/phpBB3/ 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.
> Thanks anyway, I hope someone's in the mood to be "authoritative"!
> Philip Ashmore
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
More information about the linux-rpi-kernel