spi-bcm2835: merge upstream patches allowing DMA transfers for SPI under some circumstances

[msperl]

Please merge the following Patches to drivers/spi/spi-bcm2835.c into the foundation kernel:

• torvalds/linux@3ecd37e
• torvalds/linux@7e52be0
• torvalds/linux@29ad1a7

Please also note that the device-tree needs to get added the dma tags to spi0:

        dmas = <&dma 6>, <&dma 7>;
        dma-names = "tx", "rx";

If you are unsure then add a device-tree-overlay to add it (or provide one to remove it as a fallback)

The biggest "winner" with this is the tftfb driver done by @notro...

[pelwell]

Please create one or more pull requests.

[msperl]

The last time (see #930) @popcornmix cherry-picked the patches from upstream.
Otherwise you may get merge conflicts later when you merge the upstream patches.

[popcornmix]

As long as commits are cherry-picked from upstream (rather that just being similar to) then there shouldn't be an issue. Did you want this on 4.0 or 4.1?

[msperl]

Whichever you feel more comfortable with...
Note that (most of) the code does not become active until the settings in the device-tree are done...

[popcornmix]

A PR will be useful (to also include the DT change). Can you PR to 4.1. If there are no issues it can be ported back to 4.0.

[msperl]

I will be on a business trip for the next 2.5 weeks and will not find the time until I return.

[msperl]

@popcornmix, @notro: should we enable dma by default or should we start with an overlay to enable dma?

I wonder because I am just running the cherry-picking of the patches and obviously the dma-channels needs to get configured in the device tree to be useful...

[pelwell]

Assuming you've been running with DMA enabled without problems, I would say enable it by default on 4.1, but as with the sdhost overlay we can add a DT parameter to disable it.

[msperl]

Should I merge against 4.0 or 4.1?
I would currently be merging against 4.0...

[msperl]

Notro has been doing some testing and I have used it with a fbtft device showing big bunny for 48 hours without any issues (using naked upstream 4.1)

[popcornmix]

4.0 will go to far more users (through rpi-update almost immediately and through apt-get upgrade next time we bump firmware package).
If you believe the change is beneficial and unlikely to cause regressions then PR to 4.0 (I can cherry pick to 4.1/4.2).
If you believe the change may cause issues then a PR to 4.1 is more cautious as fewer users are running that kernel (although latest OpenELEC and OSMC will be using 4.1, so there are quite a lot of users).

[notro]

I usually prefer to play safe, especially with the number of users this kernel have, so I suggest we add the patches to both 4.0 and 4.1, but we only enable DMA in Device Tree on 4.1. This way we get some testing before we hit the masses, and those that are eager to use it early on 4.0 can just make an overlay to enable DMA.
If there's no complaints, we can enable it on 4.0 later.