[PATCH] dmaengine: Add support for BCM2835.

[Martin Sperl]

Hi Andre!

I was just pointing out the fact that the value should not be hard-coded.

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.
b) I am not aware if the upstream kernel has a bcm2835_mailbox module, which
   we can use.
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.

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

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

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



Not knowing so much about politics here, I still believe that if we give 
them a chance to use upstream code directly they might become more willing
to help solve our issues (even at the cost of having some ifdefs for the 
legacy platform setup for some time - which may or may not be permissible).

And the DMA engine seems to me to be a perfect example how we could slowly
get the Foundation kernel closer to upstream by patching the "original"
dma api of theirs to call the dmaengine transparently. (even if it is just
for allocate and free)

Then at some point we could possibly have all the drivers migrated to DMA
engine and depreciate that old API.

But probably all this politics has been discussed already.

Just my 2 cent while I am trying to move to an upstream kernel and improve the
spi driver to run efficiently only using DMA...

Martin

P.s: the spi-bcm2835 is another example that can easily be made working within
the Foundation kernel. The upstream driver is already in better shape than the
spi-bcm2708 of the Foundation. 
Similar for the GPIO interrupt code, which can do level interrupts upstream, 
but is limited to edge interrupts only in the Foundation kernel.