Is something using DMA channel 0?
Richard Hirst
richardghirst at gmail.com
Sat Nov 9 15:51:57 EST 2013
(once again as plain text)
The only documentation I have is
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf,
specifically the diagram on page 5. I don't claim to fully understand
it. Maps on to peripherals do not have a problem, but if you want to
set up DMA control and data blocks in memory, and have your user space
program and the DMA controller see the same data, you need to ensure
that the cache doesn't cause a problem. I believe that if you
allocate some memory, look up the physical page addresses, and mmap
/dev/mem to access them, you end up with accesses to the lowest
mapping of the SDRAM. That mapping is L1&L2 cached from the
processors perspective, but the DMA controller will only see what you
write once it happens to get flushed from the cache in to memory, and
that can take a while depending on what is happening in the system
(and it might not happen in the order you expect, depending on which
cache lines get reused first). Similarly if the DMA controller writes
something it goes in to memory but the CPU might read stale data from
the cache and not see what the DMA controller wrote. That's what I
meant by "L1 & L2 non-coherent cached pages". To get round that you
need to access memory via one of the other mappings such that both CPU
and DMA controller always see the same data. I messed around with
using different SDRAM mappings quite a bit before deciding which
worked as I wanted it to. It's all based on a bit of guesswork
though, as the documentation is poor.
>
>
>
> Richard
>
>
> On Fri, Nov 8, 2013 at 2:14 AM, Philip Ashmore <contact at philipashmore.com> wrote:
>>
>> 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>
>> >
>>
>> _______________________________________________
>> linux-rpi-kernel mailing list
>> linux-rpi-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
>
>
More information about the linux-rpi-kernel
mailing list