I have been trying to create some ‘virtual’ spi ports without success:

I understand that the kernel supports gpio driven spi but I cannot seem to add spi numbering greater than spi1 in my device tree.
This I think is down to the definitions in the am33xx.dtsi file.

Normally it is defined as a hardware reference:
spi1: spi@481a0000 {

But I don’t have a hardware block/spi controller to address so was trying to create a “virtual” spi controller.

I thought that it should be possible to define an spi port that uses just the gpio lines and the kernel driver bit-bangs the pins to create the software controlled spi functionality.

I have been trying to do this:

/********************* PINMUX ************************/

spi4_default: spi4_default {
pinctrl-single,pins = <
/* SPI 4 /
gpmc_advn_ale.gpio_sclk /
gpmc_be0n_cle.gpio_d1 /
spi CS0 */


spi4_sleep: spi4_sleep {
pinctrl-single,pins = <
/* SPI 4 reset value /
spi CS0 */



spi4:spi4 {
pinctrl-names = “default”, “sleep”;
pinctrl-0 = <&spi4_default>;
pinctrl-1 = <&spi4_sleep>;

compatible = “spi-gpio”;
#address-cells = <0x1>;

gpio-mosi = <&gpio2 2 0>;
gpio-sck = <&gpio1 15 0>;
cs-gpios = <&gpio2 5 1>;
num-chipselects = <1>;
status = “okay”;

ioctrl@0 {
compatible = “fairchild,74hc595”;
reg = <0>;
#gpio-cells = <2>;
registers-number = <4>;
spi-max-frequency = <100000>;

This is not being done as an overlay it is part of the main board device tree for the kernel.

I have also tried different combinations of declaring the device:
spi4: spi4@0 {

spi4: spi4 {



and none of them are successful :frowning:

Can anyone please cast some light on how this would be done ?

Thank you in advance.



The device tree is for mapping functions to hardware and controlling the pin-mux to get the signals in and out.

I think the hardware configuration used by the device tree compiler knows that it only has two SPI hardware peripherals, so it won’t let you define any more.
You can define the required pins as GPIO, and write a driver that bit-bangs the SPI interface, but you will need to call it something different than regular SPI.
The device tree will understand the GPIO pins, but not much more.
It will run about an order of magnitude slower than the hardware peripheral, and have a lot of OS induced jitter.
This may or may not be a problem in your application.
You could also implement an additional SPI interface in each PRU that would work much more like a hardware peripheral.
But once again, the device tree will not recognize it a regular SPI interface, just some I/O pins that are assigned to the PRU.

— Graham