Is something using DMA channel 0?

Sat Nov 9 02:25:00 EST 2013

On 09/11/13 00:59, Philip Ashmore wrote:
> On 09/11/13 00:42, Philip Ashmore wrote:
>> On 08/11/13 21:09, Craig McGeachie wrote:
>>> On 11/08/2013 10:32 PM, Philip Ashmore wrote:
>>>> What I really wanted was an API (/proc or /sys?) place to lookup what
>>>> DMA channels videocore uses that neither user programs nor the kernel
>>>> should use.
>>>
>>> If you want this, then it's likely you will have to write it yourself.
>>> See links to information about mailbox and properties at the end.
>>>
>>>> I don't know about mailboxes - can you provide a link?
>>>
>>> Yes.  See below [3,4,5,6].  There's not much but I don't think there is
>>> much that is publicly known.  I think most of it was deduced by Simon
>>> Arlott and Stephen Warren.  I have absolutely no idea how they did it.
>>>
>>>> Progress in any direction is still progress.
>>>> When I don't know something I ask. Is there someone I/we/you can ask?
>>>
>>> I think the Linux kernel forum [1] at raspberrypi.org would be your best
>>> bet.
>>>
>>>>> It's also occurred to me to ask, if 0 is problematic, why don't you
>>>>> simply try using another channel?  I think 4 or 5 ought to be good.
>>>> Until a new boot loader comes along and breaks things.
>>>>
>>>> Co-ordinating resources isn't a new thing in software development - once
>>>> again this needs to be escalated and a formally agreed system used,
>>>> otherwise we're just pi**ing in the wind hoping we're facing the right
>>>> way.
>>>>
>>>> There's no use pretending otherwise.
>>>>
>>>> Your advice may be 100% correct at this time and be 100% wrong next
>>>> month.
>>>>
>>>> Sorry to be frank, but I'd rather be developing code that had some
>>>> chance of being future proof.
>>>>
>>>> To do otherwise is wasted effort or job security, depending on your view
>>>> point.
>>>
>>> Oh, I heartily agree.  That being the case I think your best course of
>>> action is as follows.  Accept that the videocore has authority over
>>> which channels are for it and which channels the ARM core will use.  It
>>> doesn't take requests or advice.  At best, it makes this decision once,
>>> up front, and doesn't need to be constantly asked.  For the channels
>>> usable by ARM code, the kernel DMA controller driver is in charge.  The
>>> current implementation (arch/arm/mach-bcm2708/dma.c from [2]) doesn't
>>> let you nominate which channel you will use, but lets you ask for a
>>> channel that meets criteria that you supply.  Maybe.  If there are no
>>> channels available that meet your criteria, it will still allocate one
>>> in the hope that it's good enough, which most of the time it will be.
>>> Specifically there is bcm_dma_chan_alloc and bcm_dma_chan_free.
>>> bcm_dma_chan_alloc will return the IO memory base for the channel to
>>> you, and the associated Linux IRQ number.  You would have to write your
>>> own kernel driver to expose these functions to kernel space.  The
>>> possible designs for this are endless, but wet-finger-in-the-air, I
>>> would guess that mmap on a character device file would be most robust,
>>> but /sysfs files would be simplest to implement as a quick-and-dirty.
>>>
>>> After you have been allocated a channel, you are then probably safe
>>> enough using it through /dev/mem rather than with the routines provided
>>> by arch/arm/mach-bcm2708/dma.c.
>>>
>>> If you want to know more about the mailbox, then see the links below.
>>> Also see the current raspberrypi.org implementation
>>> (arch/arm/mach-bcm2708/vcio.c at [2]). Note, you can only get the
>>> ARM-usable channels.  You can't request/tell the videocore that a
>>> channel is just for you.  The information is exactly the same as
>>> provided by dma.dmachans.  If you have access to this parameter, using
>>> the mailbox provides no benefit.  If you use bcm_dma_chan_alloc and
>>> bcm_dma_chan_free, they already make use of this information.
>> I believe these are for use by kernel code.
>>
>> Also, shouldn't arch/arm/mach-bcm2708/dma.c do a bitwise AND with the
>> dma channels it knows the BCM2835/videocore uses so it doesn't allow
>> channels used by videocore to be allocated by kernel modules?
>>
>> See below as to why I don't need to write a kernel module - I think the
>> term "command line" as in "kernel command line" - the line that commands
>> the kernel not to use certain DMA channels is sort of self-describing,
>> otherwise it would be called the "kernel optional/hints/suggestions line".
>>>
>>> Personally, I don't believe there is currently any "proper" way of
>>> sharing DMA channels without at least some kernel code.  That Richard
>>> Hist could reliably just use channel 0, and you couldn't, still baffles
>>> the s**t out of me.
>> 1. I think you meant Richard Hirst
>> I couldn't find any reference to bcm_dma_chan_alloc() in his code - can
>> you link to it or to where he uses DMA 0?
>>
>> 2. I'll dig into it tonight (I keep odd hours).
>> 3. It's probably because Richard Hirsts code doesn't use DMA chains, I
>> could be wrong.
>>
>> I've got a DMA control block "chain" that's slowed down by PWM writes.
>> The chain is closed so it just keeps going around and around while the
>> program checks the DMA control register periodically (in user space) to
>> see when it's safe to read a complete block of captured GPIO pin data
>> while the DMA is filling the other one. The DMA writes to physical
>> addresses, the user space code reads from virtual addresses.
>>
>> There are no opportunities for other processes to quickly use DMA 0 and
>> then go away, is that what Richard Hirst's code does?
>>
>> Once the control block chain has been dropped due to a DMA 0 reset it
>> will never come back.
> I just thought of something.
> If you're talking about PiFM then yes, it uses a DMA chain too.
> My program not only writes to the console, it also stores data to disk,
> and there's an NFS share and an SSH session active, with no display.
I'm making some progress.
It looks like something's stepping on the control blocks - probably the
DMA transfers from the GPIO pins.

The reason that it worked for varying lengths of time could be due to
the random layout of the memory pages physical addresses even though
their virtual addresses were contiguous.

I'll look into it further next shift.
> 
> Maybe SD card writes or network activity are to blame.
> 
>>>
>>> [1] http://www.raspberrypi.org/phpBB3/viewforum.php?f=71
>>> [2] https://github.com/raspberrypi/linux
>>> [3] https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes
>>> [4]
>>> https://github.com/hackerspace/rpi-linux/blob/lr-raspberry-pi/drivers/mailbox/bcm2835-ipc.c
>>>
>>> [5] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
>>> [6] http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/screen01.html
>>
>> Thanks for the links, I'll check them out.
>>
>> It's just a shame.
>> Regardless of how my efforts progress, we could be back here again in a
>> few months, after which time this thread will get added to someone elses
>> list of "handy links".
>>
>> Regards,
>> Philip Ashmore
>>
>> _______________________________________________
>> linux-rpi-kernel mailing list
>> linux-rpi-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
>>
> Digging deeper, will post updates...
> Philip Ashmore AFK.
> 
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
> 
Regards,
Philip Ashmore