Is something using DMA channel 0?
contact at philipashmore.com
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
> 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/
> But it appears that something writes to the DMA channel 0 control
> register at random intervals - I managed to get the i2s example
> 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 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
> 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.
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.__infradead.org
> <mailto:linux-rpi-kernel at lists.infradead.org>
More information about the linux-rpi-kernel