5kft Posted November 6, 2019 Posted November 6, 2019 I'm wondering if anyone has had any luck using spi-gpio to bitbang SPI on the H5... @martinayotte, I found a forum thread from a few years ago where you seemed to be looking at this area - perhaps you have an idea? Doing a typical spi-gpio DT overlay for this properly loads the spi-gpio and spi-bitbang drivers, creates /dev/spidev0.0, and allocates the gpios (verified via gpiod)...but the first problem I see is that the CS line is simply not working (cs-gpios below)...? /dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { spi { compatible = "spi-gpio"; #address-cells = <1>; #size-cells = <0>; ranges; mosi-gpios = <&pio 0 64 0>; /* PC0 */ miso-gpios = <&pio 0 65 0>; /* PC1 */ sck-gpios = <&pio 0 66 0>; /* PC2 */ cs-gpios = <&pio 0 67 1>; /* PC3 */ num-chipselects = <1>; status = "ok"; spidev { compatible = "spidev"; reg = <0>; spi-max-frequency = <500000>; }; }; }; }; }; I'm testing this on a NEO2 using dev kernel 5.3.8, and in this case I am re-using the same standard SPI lines for the HW SPI - this way I can switch between the two easily for testing. Standard HW SPI works great, of course, but the spi-gpio version doesn't. (I tested on other GPIO lines as well and the result is the same.) I hooked the CS, CLK, MOSI, and MISO lines to my scope, and did a test write spi_test through /dev/spidev0.0, and it appears that CLK is properly working, as is the test data transferred via MOSI (at least I'm seeing data bits coming across). But CS simply seems to not be working - I can't trigger properly on it (either high or low). Right off, measuring it shows it as low, when by default it should be high... I am not an expert by any means in this area, so any help/pointers/advice/thoughts would be greatly appreciated! Thanks!
martinayotte Posted November 6, 2019 Posted November 6, 2019 11 hours ago, 5kft said: I found a forum thread from a few years ago where you seemed to be looking at this area I don't recall, but you can maybe provide such link ... 11 hours ago, 5kft said: But CS simply seems to not be working Did you tried to use another plain GPIO which is not part of HW SPI ?
5kft Posted November 6, 2019 Author Posted November 6, 2019 1 hour ago, martinayotte said: I don't recall, but you can maybe provide such link Sure! https://forum.armbian.com/topic/4330-spi-gpio-chip-select-support/ - mid-way in the thread you did some nice debugging into the kernel regarding the initialization of CS. I think I need to do a similar thing to figure out why it simply isn't initializing/working... Perhaps there is no relation, but without digging into spi-gpio yet I'm wondering why it wouldn't initialize correctly...?? "gpioinfo" shows the overlay initialization working in terms of GPIO allocation: line 63: unnamed unused input active-high line 64: unnamed "mosi" output active-high [used] line 65: unnamed "miso" input active-high [used] line 66: unnamed "sck" output active-high [used] line 67: unnamed "spi0 CS0" output active-low [used] line 68: unnamed unused input active-high ...but for example measuring line 67 (PC3) the line is low, when it should be high. Very strange...! 1 hour ago, martinayotte said: Did you tried to use another plain GPIO which is not part of HW SPI ? Yes, my original test was using several other GPIOs (e.g., PG6/7 for CSN)...same effect.
martinayotte Posted November 6, 2019 Posted November 6, 2019 29 minutes ago, 5kft said: Sure! https://forum.armbian.com/topic/4330-spi-gpio-chip-select-support/ - mid-way in the thread Right ! But my debugging was for HW SPI ... I've looked quickly at drivers/spi/spi-gpio.c, it seems to be normal code, but if you wish to debug further, you can add some debug prints to make sure the initialization code and toggling code is done properly.
5kft Posted November 6, 2019 Author Posted November 6, 2019 OK, thanks! As I figured, I need to dive in deeper. I'm curious about changes like this, for example: https://lkml.org/lkml/2019/4/3/9... Looks like I have another weekend project to do!
Recommended Posts