Is something using DMA channel 0?

[Philip Ashmore]

On 08/11/13 08:53, Craig McGeachie wrote:
> On 11/08/2013 09:43 AM, Philip Ashmore wrote:
>> On 07/11/13 07:17, Craig McGeachie wrote:
>>> 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?
> 
> I don't think the videocore should do a bitwise and.  Obviously I didn't
> write the videocore bootloader, so I'm making a pretty wild guess here.
>  I think it was only meant as a quick and dirty mechanism to co-ordinate
> DMA channel usage between code running on the two different cores.  I
> don't think whoever wrote the code intended to support a general
> mechanism for configuring channels to not be managed by kernel code.  If
> I was writing videocore code, I don't think I'd be interested in parsing
> a hexadecimal number, and modifying it, rather than just doing a nice
> simple format as string and write to memory.

I didn't have my thinking cap on when I wrote this - sorry.

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.

I'm guessing the dma.dmachans parameter is ignored by the videocore.
> 
> Any code running on the same core should be able to do its own
> co-ordination.  I reckon it wouldn't be too hard to write a kernel
> driver that exposed the DMA channel reservation and allocation mechanism
> to some sort of user space API.  ioctrl or mmap on a device file maybe.
>  A sysfs handler perhaps.
> 
> There is another mechanism for ARM code to find out which DMA channels
> the videocore has permitted the ARM to use - an interprocessor call API
> from the ARM to videocore [1].  If kernel DMA code were written to use
> this, then you would have to re-write kernel code to intercept and
> change the value, and the dma.dmachans kernel command line option would
> have no effect at all.

Er, it would specify which DMA channels the kernel should never use.

And ask videocore very very nicely not to use them either, which of
course it's completely free to totally ignore.

> 
> Please don't ask why the DMA driver wasn't written to use the mailbox

I don't know about mailboxes - can you provide a link?

> call in the first place rather than introducing a command line option. I
> don't know, and it makes no sense to me.

Progress in any direction is still progress.
When I don't know something I ask. Is there someone I/we/you can ask?

> 
> 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.
> 
> Cheers,
> Craig.
> 
> [1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

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.

Regards,
Philip Ashmore