Is something using DMA channel 0?

[Philip Ashmore]

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: 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.
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.
> 
> Cheers,
> Craig.
> 
Thanks anyway, I hope someone's in the mood to be "authoritative"!

Regards,
Philip Ashmore