Add spi-gpio module and dtoverlay

[BjoernSch]

Adds support for bit banging SPI over GPIO via the spi-gpio module
Closes #2169

[pelwell]

There are a few implementation issues with this PR:

1. In order for the overlay to be built with the kernel it must be included in the Makefile inside the overlays directory.
2. The Makefile rule for overlays transforms *-overlay.dts to *.dtbo, so your overlay source file has to follow the naming convention.
3. SPI_BITBANG is automatically selected with SPI_GPIO, so don't include it in the defconfigs.
4. In order to be generally useful, the GPIO usage should be changeable via parameters.

...and an existential issue:
5. A bit-bashed SPI will have lower performance and higher CPU load than a hardware implementation, so it is normally only used when hardware SPI is unavailable or busy. Why then would you replace the hardware SPI0 with a software implementation? You may well have a good reason, but it would help to avoid confusion for other users if you would explain your reasons in the README.

[BjoernSch]

1. , 2. and 3. should now be fixed.
2. I wish to have it seen as an example overlay at the moment, because compiling the modules by yourself to match the official kernel takes hours and is a real pain.
   But creating a custom device tree overlay is done in seconds. I will try to make the example generally more useful.
3. Because you can use it with more than 2 CS lines. In our case the hardware uses gpios choosen before the hardware SPI was easily usable. But the kernel bitbanging SPI is the fastest version for this, not comparable to real hardware SPI but very useful for low data rate devices like sampling an ADC or sensor chip without having conflicting GPIO access. In this case the performance is not an issue.
   I will clarify this in the README.

[pelwell]

Compiling overlays via the kernel makefiles is quick and easy (once you've downloaded the kernel source tree...) - just use dtbs as the make target.

Your new overlay is fine, but your answer to 3 means that most of it is unnecessary. The hardware SPI driver can make use of any GPIO as a software-controlled chip select line - just add them to the cs-gpiosproperty.

[BjoernSch]

I think it would still be useful as an possibility to add an additional SPI bus, especially for slow sensor devices. Using the existing CS in the example lines was not very lucky for general use, I think.

[pelwell]

But your patch effectively disables the SPI0 hardware interface, which is less useful.

To be accepted, the spi-gpio interface would have to appear as spidev3.x so as not to clash with any of the hardware interfaces.

[Swap-File]

Software bit banging can still be useful even with unlimited chip selects, but I agree that I wouldn't want bit banging to override the hardware SPI in any way.

Example use case: I had a project where I needed to drive a TFT screen with fbtft and a string of 20 APA102 LEDs both via SPI. While I was able connect them both to the hardware SPI interface and write to both of them, the massive amount of data being sent to the screen caused visible jitter in animations sent to the LEDs. My solution was to let the SPI display have the hardware SPI all to itself and bit bang the LEDs.

[dsvensson]

A bit off-topic maybe, but currently SPI interaction seems to automatically do CS, so that if I try two transfers within my explicit CS low/high section, the second transfer returns an invalid buffer. I suspect the kernel does the CS automatically even if I pass SPI_NO_CS. Would this PR fix that?

[pelwell]

Do you have a small test program (C, Python etc.) that demonstrates the problem? Please start another issue - it makes it easier to track progress etc.

[shenghaoyang]

If the author is still working on this, another probable use case is for those HAT manufacturers that create HATs with SPI peripherals but connected to non-hardware SPI pins. Sure, you could always bitbang the SPI bus, but when you mix that with seccomp the overhead is quite significant. I've had a simple LED daemon's CPU usage rise from 4% to 24% when I enabled seccomp on it through systemd, simply because it was making so many system calls while bitbanging. (E.g. Pimoroni Blinkt)

Thing is, I don't think a fixed overlay should be included, anyway. The huge amount of flexibility associated with the bitbanged SPI bus (single / multiple / no chip select / tx only mode / rx only mode / etc) really can't be expressed with that. Could the modules simply be enabled? - That would resolve the issue around the implementation of the overlay. Those using this module would probably need to write their own overlay, anyway, to deal with their own specific issues.

[pelwell]

Could the modules simply be enabled? - That would resolve the issue around the implementation of the overlay. Those using this module would probably need to write their own overlay, anyway, to deal with their own specific issues.

That works for me, and it doesn't preclude somebody coming back later with a better overlay.

[pelwell]

CONFIG_SPI_GPIO=m is now defined in rpi-4.14.y, so the module will be in future builds.

[BjoernSch]

May I close the issue now? I´m happy.

[pelwell]

Allow me.