RPi3: not enough DMA channels for SPI+I2S

[HiassofT]

I received a report that the Cirrus audio card, which needs both SPI and I2S, doesn't work on the RPi3:
http://openelec.tv/forum/124-raspberry-pi/69870-wolfson-audio-card-support?start=270#159249

Looking at dmesg http://sprunge.us/Fjdc it seems like we have the same problem again like last summer (issue #1110) - the kernel is short of one DMA channel and requesting the second DMA channel for bcm2835-i2s fails

[    4.551417] bcm2708-i2s 3f203000.i2s: Missing dma channel for stream: 1

On the RPi1/2 when SPI+I2S is used only one DMA channel is free, and since on RPi3 mmc-bcm2835 seems to want 2 DMA channels as well we have a problem.

As a quick workaround using spi-bcm2708 (which doesn't use DMA) instead of spi-bcm2835 on kernel 4.1 seems to work fine, but it looks we don't have a similar option on kernel 4.4 (or for people who need DMA-supported SPI).

Ideally we'd have at least one more DMA channel available, that would solve this problem.

I don't have my RPi3 yet so currently can't test myself but I think the issue should be easily reproducible with "dtparam=spi=on,i2s=on".

ping @popcornmix @pelwell @msperl @notro

[msperl]

there is one patch that went into the foundation kernels with regards to more dma channels.
On top there is now a recently posted patch to dma-engine for upstream, that:
a) releases one more dma channel for use (channel 2 if I remember correctly)
b) allows us to use dma channel 11 to 14 correctly (by using the shared irq)

[HiassofT]

@msperl Thanks! Could you please post a pointer to your latest patches, they don't seem to have hit the linux-rpi-kernel list

[msperl]

it has not hit the rpi-list yet (probably because of moderation), but it is on the arm list...
http://archive.arm.linux.org.uk/lurker/message/20160305.105211.40e3c813.en.html

And there patch2 and patch3:
http://archive.arm.linux.org.uk/lurker/message/20160305.105213.f91facb2.en.html
http://archive.arm.linux.org.uk/lurker/message/20160305.105214.9c11d4d0.en.html

[msperl]

Note that the main reason seems to be that as of now on a RPI3 we have 4 dma channels already
used:

• 2 for MMC
• 2 for SDHCI/SDIO (used by WLAN)
  that leaves - with the current foundation setup - 3 dma channels for use...

The patchset for upstream gives you instead a grand total of 11 dma channels - leaving 7 for free use.
Still there may be some advantage of disabling the Wifi card if it is not used - this may also disable SDHCI...

[HiassofT]

@msperl thanks a lot, your channel 12-14 patches seem to be working fine!

Here's my tree (rpi-4.4.y plus your patches): https://github.com/HiassofT/rpi-linux/tree/dma-channels-12-14

I'll do some more testing and then create a PR.

Just a minor note: in the commit message of the DMA patch and in the DT docs example you have brcm,dma-channel-shared-mask at 0x0780 instead of 0x7800. I copied the DT settings from there and then was wondering for a short moment why it didn't work :)

Having a possibility to disable SDIO/BT/WiFi would certainly be nice.

[msperl]

ok - a typo...

Bt can get disabled via an overlay!

[msperl]

probably sdhost could as well get disabled via a device tree overlay - something along those lines:

/dts-v1/;
/plugin/;

/{
    compatible = "brcm,bcm2708", "brcm,bcm2709", "brcm,bcm2710";

    fragment@0 {
        target = <&sdhost>;
        __overlay__ {
            status = "disabled";
        };
    };
};

[msperl]

Looking at the reason behind this: probably a different option would be disabling dma for spi - especially as - I assume - spi is only used rarely and then only for configuration... (And probably only for transfer sizes that will not be handled via dma anyway)

[HiassofT]

Looking at the reason behind this: probably a different option would be disabling dma for spi - especially as - I assume - spi is only used rarely and then only for configuration... (And probably only for transfer sizes that will not be handled via dma anyway)

I fully agree. Having SPI DMA disabled by default plus a spi-dma overlay like we had some time ago (and is still present in the 4.1 tree as a relic) would be the best solution IMHO. People who want to have DMA on SPI could manually enable it and overlays absolutely requiring SPI DMA could just include the overlay in the dts. DMA channels are a scarce resource, better not waste them... Also an overlay/dtparam to disable mmc/sdio on RPi3 when it's not needed would be nice. @pelwell what do you think?

[pelwell]

Actually it already exists - dtoverlay=sdhost.

[HiassofT]

Actually it already exists - `dtoverlay=sdhost`.

Thanks @pelwell I completely missed that :( What's your opinion on the DMA topic?

[msperl]

unfortunately it is not as simple - people with tft displays WANT spi to use DMA.
I guess it would require an overlay to make it optional for people with "more complex" needs, who hopefully know what they do...

[msperl]

@pelwell : your overlay is slightly different - use sdhost, but not disable sdhost only while still using mmc for the sdcard (but it - mostly - achives a similar effect)

[pelwell]

Let's enable as many as we can (thanks, @msperl - we should back-port your patch set) and use as few as possible.

Something else to bear in mind - the sdhost driver has a PIO-only mode. Add dtparam=sd_force_pio (once you've grabbed and built the very latest source - it was missed out of the initial Pi3 DTB).