[PATCH] dmaengine: Add support for BCM2835.

[Andre Heider]

Hi Martin,

On Sun, Nov 10, 2013 at 02:27:39AM +0100, Martin Sperl wrote:
> 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.

u-boot and barebox already have a bcm2835 mbox driver, and there is a mbox
property to get the dma channel mask [0], which is exactly what the VC
bootloader start.elf passes on via the dma.dmachans parameter.

That makes it trivial to query that mask in the bootloader. Now we could
add that mask to the device tree (with a default of 0x0) and let the
bootloader fix it up.

> 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!

That sounds backwards to me. Why should we abandon the freedom to use an
open bootloader and hope that bcm implements stuff that's only useful
for upsteam drivers, when all they care about is their own downstream
community?

> 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

[0] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#get-dma-channels

Regards,
Andre