Is something using DMA channel 0?
slapdau at yahoo.com.au
Fri Nov 8 03:53:17 EST 2013
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.
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 . 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.
Please don't ask why the DMA driver wasn't written to use the mailbox
call in the first place rather than introducing a command line option.
I don't know, and it makes no sense to me.
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.
More information about the linux-rpi-kernel