[PATCH] dmaengine: Add support for BCM2835.

[Andre Heider]

Hey Martin,

On Sun, Nov 10, 2013 at 06:20:41PM +0100, Martin Sperl wrote:
> Hi Andre!
> 
> I was just pointing out the fact that the value should not be hard-coded.

yes, and I agree with that ;)

> I have proposed several options - not stating any preference.
> (Not fully knowing what the overall design directive is from the several
> upstream maintainers)
> 
> I know, that there is the mailbox API, but:
> a) I am not fully aware that uboot is querying all those parameters from the 
>    wiki you have mentioned and is adding them to the device tree right now.

It's querying the ARM memory size and sets up a frame buffer for simplefb.
Both infos are passed on to the kernel using device tree.

> b) I am not aware if the upstream kernel has a bcm2835_mailbox module, which
>    we can use.

Patches have been posted multiple times for a driver on this list, but not
merged as of today.

> c) I am not sure if it is better to call the mailbox api from the driver
>    or read the data from the device tree.

Right now, considering that we have a) but not b), the latter seems like
the obvious choice. And since the dma channel mask is consistent over a
power cycle I'd think it's a sane choice.

> I am just saying that hardcoding is the worst solution of it all...
> 
> The more knowledgeable people need to decide on the preferred way.
> 
> But as a warning:
> Just implementing it in uboot when we need it would mean that everyone will
> need to update the boot-loader whenever a new feature is activated that requires
> a new value from the GPU , which makes moving forward for the individuals more
> painful than necessary...

Correct. But if we put the mask in the device tree and let the boot loader
fix it up we're in the same situation as with the introduction of simplefb:
It'll only work if the boot loader supports it.

But in the RPi's case, start.elf as well as u-boot are just second stage
boot loaders, which are just a file on SD card. That makes updates
non-critical and not as painful as seen on other boards where you have
to flash new binaries with the danger of bricking the device.

> >> 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?
> 
> Depends on how important the boot-time becomes - I am just pointing out that
> it is in principle possible to run from start.elf directly.

It's not just about boot time, there're different features to consider
too. If you use the VC loader with its device tree capabilities to boot
an upsteam kernel you'll lose the simplefb node, so no graphical output.
And I'm not sure if it properly fixes up /memory considering the ARM/VC
memory split.

> I did NOT say that we should change back to the "main bootloader", but just
> point out that it could work in principle.

Sorry if that sounded aggressive. Please consider the tone a reflection
of the frustration with vendors who don't get the advantages of working
upsteam.

Regards,
Andre