Is something using DMA channel 0?

[Philip Ashmore]

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
they?
> 
> Richard
> 
> On 7 Nov 2013 07:18, "Craig McGeachie" <slapdau at yahoo.com.au
> <mailto:slapdau at yahoo.com.au>> 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/
>         <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
>         <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
>         <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
>     <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.
> 
>     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
>     http://www.raspberrypi.org/__forum
>     <http://www.raspberrypi.org/forum> would have been a better place.
> 
>     Cheers,
>     Craig.
> 
> 
>     _________________________________________________
>     linux-rpi-kernel mailing list
>     linux-rpi-kernel at lists.__infradead.org
>     <mailto:linux-rpi-kernel at lists.infradead.org>
>     http://lists.infradead.org/__mailman/listinfo/linux-rpi-__kernel
>     <http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel>
>