[PATCH] dmaengine: Add support for BCM2835.
martin at sperl.org
Sat Nov 9 17:27:39 PST 2013
Thanks for your work - I will hopefully be able to benefit from this
dma-engine for the RPI soon.
As mentioned in private communication already, you have defined:
> #define BCM2835_DMA_CHANNEL_MASK 32565
This essentially defines the DMA channels that are available to ARM
as a bitmask.
The problem is that the DMA channels are shared between VideoCore GPU and
ARM and the VideoCore GPU Firmware also uses some DMA Channels for its
own purpose (CSI or DSI, maybe others) - hence the mask is not 32767,
which would to allow all 14 Channels (Channels 1,3,6 and 7 are currently
reserved by VideoCore - at least in my configuration).
But obviously this use may change with firmware revisions of the GPU.
Also keep in mind that the GPU is actually controlling the boot-sequence
and its firmware contains a boot-loader to boot the ARM from VideoCore.
This bootloader reads from (/boot)/config.txt the parameters which "kernel"
to load - typically the Raspbien Kernel or u-boot.
But it also reads additional kernel parameters from (/boot)/cmdline.txt
which it passes to the "kernel" it boots. This second file is redundant for
the u-boot case, as these parameters can be defined in u-boot itself.
But the VC-bootloader also adds an extra set of parameters to the kernel
parameters, containing some interesting information about the system setup.
On my system this Firmware-provided parameters look like this:
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
vc-cma-mem=0/0x1c00000 at 0x1d000000 mem=0x1c000000 at 0x0
mem=0x1c00000 at 0x1d000000 vc_mem.mem_base=0x1ec00000
In this case 512MB Ram with initially 64MB assigned to the GPU plus some
dynamic memory sharing parameters.
These get stored as ATAGS in memory from 0x100 (unless "deconfigured" via
disable_commandline_tags in (/boot)/config.txt).
And if you look at the above it contains "dma.dmachans=0x7f35" which is
incidentally 32565, which you have defined as BCM2835_DMA_CHANNEL_MASK.
So the firmware is providing some information about DMA slots it is using
during the boot-sequence.
I do not know how u-boot would be able to handle these "extra" ATAG parameters
and how to make it possible for u-boot to forward them to the kernel, but there
is hopefully a way.
So I see it as a big risk hardcoding this anywhere in code or in the
device-tree, as this may change with firmware revisions and/or attached HW
(to enable extra features - the video-decoders or camera modules come to mind
On the other hand - the VideoCore ARM-bootloader has some means of providing
a device tree as well (via (/boot)/config.txt and the parameters device_tree
If it can "modify" the device-tree it load and add such information or not
is a different question. It would require communication with the
firmware-developers to confirm if this functionality is available.
If all this really works as expected, then we could even boot a device tree
kernel without the extra u-boot step in between!
But in reality, this is a more general setup question of how the GPU
firmware (which is the actual "master" booting the SOC) communicates with
the ARM-kernel about initial settings during the boot-phase.
The module "parameter" approach would be one way - uboot passing the values
from the "GPU-bootloader".
Another option could be adding extra "glue" code in u-boot that would
translate these kernel parameters (now passed to uboot) and enhance the
loaded device tree with the provided values.
As Stephen coded board/raspberrypi/rpi_b/rpi_b.c in u-boot and he already
makes use of some of those parameters (RAM-Size,...) he might be able to
elaborate on options to query the Firmware about the other parameters that
may be of interest to us. But for each and every new "value" we may need
to patch u-boot, so maybe not such a good idea either...
Maybe you want to query the settings via the mbox call directly from your
The question here is: do we have the available framework "yet" in the
kernel or would it also require to write an mbox driver for the RPI -
maybe based on a generic version (if such exists).
More information about the linux-rpi-kernel