Add spi-gpio support

[BjoernSch]

This would require to enable spi-gpio (and spi-bitbang as dependency) as module.
Afterwards you could add additional software SPI devices via device tree overlays on freely choosen GPIOs.

[pelwell]

Have you tried this on a Pi? How well does it work?

[BjoernSch]

I have tested it on a Raspberry Pi Zero W.
It works very good in my case, I tested it with an generic ADC + 2 thermocouple converter on a single bus.
I could provide a module working with the current kernel and the device tree overlay I used.

[pelwell]

I'm interested to see the overlay - we'd want to add one to the standard image to make the new driver usable.

[BjoernSch]

Here it is:
https://gist.github.com/BjoernSch/39d3bca950a3b025b806decc2b686bbc
(The choosen GPIOs may not be the best choice for the general public.)

[BjoernSch]

Current version of the overlay, includes debian packaging:
https://github.com/BjoernSch/dto-spi-gpio-wlanthermo/blob/master/spi-gpio-wlanthermo.dts
Building the module manually is still a real pain.
Enabling the option should "only" add two modules, as they are running with the stock kernel even if build on an external system, so no high costs and a lot of possibilities for SPI usage added.

[pelwell]

If you put the overlay in a Pull Request along with a README patch and the required config updates - see #2252 for a very recent example - it should get merged quickly.

[JamesH65]

@BjoernSch Did this PR happen?

[BjoernSch]

Not yet, but I will take care of it this week.

[JamesH65]

@pelwell I suspect since the referenced PR #2318 was apparently merged recently, this can be closed?

[pelwell]

Not exactly - we've enabled the required driver in the standard kernel builds, but users will need to modify and build their own overlays.

[dsvensson]

@pelwell Is the steps needed to be taken documented anywhere to get this working?

[pelwell]

1. Download an overlay (e.g. https://github.com/raspberrypi/linux/pull/2318/files#diff-b52f412d816937d23af7f07caa747039) - we'll call it spi-gpio-overlay.dts for the purposes of this example.
2. Edit the GPIOs (look for <&gpio ...>) as needed.
3. dtc -@ -I dts -O dtb -o spi-gpio.dtbo spi-gpio-overlay.dts. Don't worry about warnings - there are likely to be a few.
4. sudo cp spi-gpio.dtbo /boot/overlays
5. Add dtoverlay=spi-gpio to /boot/config.txt.
6. Reboot.

[dsvensson]

@pelwell is this kernel version available yet in Raspbian Stretch, or is there some nightly kernel repository?

My raspberrypi-kernel version is: 1.20180417-1

Linux raspberrypi 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l GNU/Linux

[pelwell]

That is the most recent Raspbian release, but you can download 4.14.52 using sudo rpi-update.

[dsvensson]

@pelwell That causes the spidev device to disappear. I was hoping to keep using that, just that I want to write to the CS pin to be able to run multiple transfers within one toggle. Seems like the spidev by defaults toggles CS based on transfer() calls. My usecase is that I have a radio data frame I want to read out, but I want to read out the header separately, and the payload to a statically allocated buffer, so I want to call transfer first with the address and enough room for the header, then again, with the API user supplied buffer to read out the payload. If I try that today, I get garbage unless I pass address in the first byte in the argument of the second transfer. Was hoping this would fix that. Any idea?

[pelwell]

The spidev API structure spi_ioc_transfer includes a flag - cs_change - that controls whether the CS line is held between transfers. I discussed it in detail in this issue: lthiery/SPI-Py#17, but the quick version is that it inverts the usual behaviour of CS:

• A message is composed of one or more transfers. Each call to the SPI_IOC_MESSAGE ioctl constitutes a single message, and the number of transfers is controlled by the size of the array passed to the call.
• The normal behaviour is to keep CS asserted between transfers within a message, then to deassert it between messages.
• Setting cs_change for a transfer in the middle (strictly, not at the end) of a message will deassert CS briefly before moving on to the next transfer.
• Setting cs_change for the last transfer in a message will keep it asserted until the next message.

By carefully setting the cs_change flag on each transfer you can create arbitrary patterns of CS usage.

[dsvensson]

@pelwell This is getting slightly off-topic, but what you say does not seem to prevent the CS from changing under my feet according to my experiments. Rust's spidev crate leaves cs_change at 0, and yet it changes (my second transfer needs the same address at buffer[0] as the first transfer to continue the read, which is not expected right?). It kind of sounds like the following issue:

https://www.raspberrypi.org/forums/viewtopic.php?t=195600

Any suggestions? Can't find the bug that could have been the output of that thread, and don't feel like I have the knowledge myself to file such a bug myself with meaningful information.

[pelwell]

If you want to keep CS asserted indefinitely you need to set cs_change=1, but only for the last transfer in each message. If that doesn't make sense, read my previous reply again until it does.

[dsvensson]

So I do:

1. Set CS pin to low.
2. Perform SPI transfer, buffer[0] = someaddress, which on Linux uses spidev. Buffer comes back with good data, but buffer[0] is wasted.
3. Set CS pin to high.

I guess this has no affect, and I could just as well have ignored setting the CS pin via GPIO.

In other cases I have this:

1. Set CS pin to low.
2. Perform SPI transfer, buffer[0] = someaddress, large enough to eat a few bytes of the payload, a header in this case.
3. Perform SPI transfer, buffer2 (previous transfer did not eat everything, this buffer should only contain payload after transfer)
4. Set CS pin to high.

I have re-read your reply, but to me it sounds odd that changing cs_change the last transfer makes the first transfer not fiddle around with the CS.

The reason I mention explicitly setting CS here via GPIO is that I'm using the linux-embedded-hal which is a Linux implementation of the generic embedded-hal. Compiling my library for some embedded target would toggle ports and do the SPI dance there instead without spidev being involved.

Is it perhaps impossible to disable automatic CS-stuff on raspberry pi when using spidev? Really just want it to hands-off the CS, as I'm expected to control CS manually if the library is deployed on other platforms than Linux.

[pelwell]

Reading the code, the spi-bcm2835 driver does support SPI_NO_CS, but only when using chip-selects driven by the hardware. As a work-around for a bug in the hardware, the driver automatically converts hardware chip selects into GPIO chip selects which are then managed by the common SPI subsystem. Unfortunately this layer doesn't seem to honour SPI_NO_CS, leaving you in the situation you are in now (unless you manage to make use of the cs_change flags).

There are a few options available:

1. Make the framework honour SPI_NO_CS - this has to be the correct solution, and should only be a few lines of code. I'm puzzled why this doesn't already exist - am I missing something?
2. Use the spi0-hw-cs overlay to use the hardware chip selects, which should allow SPI_NO_CS to work as intended.
3. Use the spi0-cs overlay to change the pin the framework uses for CS, leaving your code to manage the real CS line.
4. Use an alternate pin for CS, leaving the framework to manage the usual pin (the inverse of 3).

What are your thoughts?

[dsvensson]

@pelwell My thoughts are centered around how grateful I am for your help. I applied the spi0-hw-cs overlay, configured spi with SPI_MODE_0 | SPI_NO_CS, and GPIO pin 8 (24 physical). I now get the expected behavior in my library! I don't even remember how many hours I've put into brute-forcing this problem. A huge thanks for making the effort of explaining this to me!

[pelwell]

I've pushed a one-line patch that adds SPI_NO_CS support for GPIO chip-selects. Once you have a kernel with that patch you should be able to remove the spi0-hw-cs overlay and still be able to drive the CS line as you wish.

[pelwell]

Last night's rpi-update kernel+firmware release includes the SPI_NO_CS patch.

[openedhardware]

1. Download an overlay (e.g. https://github.com/raspberrypi/linux/pull/2318/files#diff-b52f412d816937d23af7f07caa747039) - we'll call it spi-gpio-overlay.dts for the purposes of this example.
2. Edit the GPIOs (look for <&gpio ...>) as needed.
3. dtc -@ -I dts -O dtb -o spi-gpio.dtbo spi-gpio-overlay.dts. Don't worry about warnings - there are likely to be a few.
4. sudo cp spi-gpio.dtbo /boot/overlays
5. Add dtoverlay=spi-gpio to /boot/config.txt.
6. Reboot.

@pelwell

I have followed your instruction on my Raspberry Pi 0 W (Raspbian Buster Lite), but SPI is not working though...
My overlay file:

/dts-v1/;
/plugin/;
/{
    compatible = "brcm,bcm2708";
    fragment@0 {
        target = <&spi0>;
        #address-cells = <1>;
        #size-cells = <0>;
        __overlay__ {
            compatible = "spi-gpio";
            #address-cells = <1>;
            #size-cells = <0>;
            ranges;
            gpio-mosi = <&gpio 24 0>;
            gpio-sck = <&gpio 22 0>;
            gpio-miso = <&gpio 23 >;
            cs-gpios = <&gpio 25 1>;
            num-chipselects = <1>;
            status = "ok";
            spidev@1{
                compatible = "spidev";
                reg = <0>;
                spi-max-frequency = <2000000>;
            };
        };
    };
};

And the execution result:

pi@raspberrypi:~$ dtc -@ -I dts -O dtb -o spi-gpio.dtbo spi-gpio-overlay.dts
spi-gpio.dtbo: Warning (avoid_unnecessary_addr_size): /fragment@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property

After I have copied the .dtbo file to /boot/overlays and rebooted, I am seeing /dev/spidev0.0, but dmesg is:

raspberrypi:~ $ dmesg | grep spi
[   14.964013] OF: /soc/spi@7e204000: arguments longer than property
[   14.978327] spi_gpio 20204000.spi: chipselect 0 already in use
[   14.978358] spi_master spi0: spi_device register error /soc/spi@7e204000/spidev@1
[   14.978385] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/spidev@1

And the RC522 reader is not working with the new SPI bus...

Any idea?

Thanks!

P.S. I even tried to start the overlay manually:

raspberrypi:~ $ sudo dtoverlay spi-gpio
pi@raspberrypi:~ $ dmesg | grep spi
[   14.964013] OF: /soc/spi@7e204000: arguments longer than property
[   14.978327] spi_gpio 20204000.spi: chipselect 0 already in use
[   14.978358] spi_master spi0: spi_device register error /soc/spi@7e204000/spidev@1
[   14.978385] spi_master spi0: Failed to create SPI device for /soc/spi@7e204000/spidev@1
[  342.141293] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/compatible
[  342.141324] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/ranges
[  342.141336] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/gpio-mosi
[  342.141346] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/gpio-sck
[  342.141356] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/gpio-miso
[  342.141373] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/cs-gpios
[  342.141383] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/num-chipselects
[  342.141394] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/status
[  342.141410] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/spidev@1/compatible
[  342.141419] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/spidev@1/reg
[  342.141431] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/spidev@1/spi-max-frequency