[PATCH] dmaengine: Add support for BCM2835.

[Martin Sperl]

Hi Florian!

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 
bcm2708.boardrev=0xf bcm2708.serial=0xAABBCCDDEEFF 
smsc95xx.macaddr=82:27:DE:AD:BE:EF sdhci-bcm2708.emmc_clock_freq=100000000
vc-cma-mem=0/0x1c00000 at 0x1d000000 mem=0x1c000000 at 0x0 
mem=0x1c00000 at 0x1d000000 vc_mem.mem_base=0x1ec00000
vc_mem.mem_size=0x20000000

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
as candidates...)

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
and device_tree_address)

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
driver? 
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).

Ciao, Martin