Is something using DMA channel 0?

[Philip Ashmore]

Oops!
http://www.raspbian.org/RaspbianDocumentation
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
>>> 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
> 
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
>