How many SPI ports/buses are broken out/available on SOQUARTZ?

[gogerriko]

I am interested in the SOQUARTZ compute module, but before I commit to getting one I am trying to work out how many SPI ports/buses are available for my potential application as I need 2 (for technical reasons using 1 SPI bus with multiple CS pins is not possible).

As far as I can tell from the schematic only SPI3 is available on CN1 100 pin connector.

I could see any obvious SPI options on CN2.

As I do not need to use the WiFi / BLE module is there any way I can access SPI1 / SPI2

I look forward to any feedback.

Thanks.

[CounterPillow]

I looked at the schematic and datasheet to figure out whether there's any way to access SPI1/SPI2 with a different pinmux, and it doesn't seem to be the case. Seems like this module sadly won't work for your use-case.

[gogerriko]

I looked at the schematic and datasheet to figure out whether there's any way to access SPI1/SPI2 with a different pinmux, and it doesn't seem to be the case. Seems like this module sadly won't work for your use-case.

You've almost addressed my next question. 

I'm now re-evaluating my own options to see if I can change my application code to use the same SPI bus but flip between slave devices using different CS (chip select) - it's messy, a little complex with timings, but possible.

As such, it is not clear to me how to define my two CS's inside the device tree overlay. 

Are the pin control pinmux references preset for each CS or do I still need to add inside the device tree overlay for my spi driver? If so, where do I find this pinmux table?

I also note that there are various device tree overlay templates found on the radxa github repository page (https://github.com/radxa/overlays/) which are applicable for use with RK386x chipsets and are defined as compatible with "rockchip". I assume these are suitable for use with the Pine64 SOQuartz board.

So assuming that's the case, and as SPI3 is available on the SOQuartz, am I correct to then create an overlay fragment for <&spi3> and then use the same pinctrl-0 pin references for CS0: <&spi3m0_cs0 &spi3m0_pins>;

Then what about CS1, as I noticed that Radxa's own compute module (RK3566 CM3) uses a different pin number here. Do I then assume that you have correctly linked the reference  &spi3m0_cs1 to the correct pin in the RK3566. As I don't have visibility on how this all works, it is hard to know.

I look forward to your feedback.

Thanks.

[CounterPillow]

I looked at the schematic and datasheet to figure out whether there's any way to access SPI1/SPI2 with a different pinmux, and it doesn't seem to be the case. Seems like this module sadly won't work for your use-case.

You've almost addressed my next question. 

I'm now re-evaluating my own options to see if I can change my application code to use the same SPI bus but flip between slave devices using different CS (chip select) - it's messy, a little complex with timings, but possible.

As such, it is not clear to me how to define my two CS's inside the device tree overlay. 

Are the pin control pinmux references preset for each CS or do I still need to add inside the device tree overlay for my spi driver? If so, where do I find this pinmux table?

I also note that there are various device tree overlay templates found on the radxa github repository page (https://github.com/radxa/overlays/) which are applicable for use with RK386x chipsets and are defined as compatible with "rockchip". I assume these are suitable for use with the Pine64 SOQuartz board.

So assuming that's the case, and as SPI3 is available on the SOQuartz, am I correct to then create an overlay fragment for <&spi3> and then use the same pinctrl-0 pin references for CS0: <&spi3m0_cs0 &spi3m0_pins>;

Then what about CS1, as I noticed that Radxa's own compute module (RK3566 CM3) uses a different pin number here. Do I then assume that you have correctly linked the reference  &spi3m0_cs1 to the correct pin in the RK3566. As I don't have visibility on how this all works, it is hard to know.

I look forward to your feedback.

Thanks.

The pinctrl for the m0 pinmux is already in the base device tree of rk356x.dtsi, no overlay is needed to change the pinmuxes in this case. When you're writing a device tree overlay to enable SPI, you can simply leave out the pinctrl properties; the ones from the base tree will be used.

If you had to change some pinmuxes, you'd do it by copying the definitions of the pins from rk3568-pinctrl.dtsi to your overlay first, as they get omitted from the base tree if there's no reference. I plan on writing some example overlays myself for SPI stuff on soquartz over at https://github.com/CounterPillow/overlay-examples soon, I just haven't gotten around to it yet.

In general, I would not try to use radxa's overlays; I'm pretty sure they target their own probably downstream based kernels.

[gogerriko]

I plan on writing some example overlays myself for SPI stuff on soquartz over at https://github.com/CounterPillow/overlay-examples soon, I just haven't gotten around to it yet.

Yes, that would be really helpful. 

UPDATE:
I thought I understood what to do based on the Radxa overlays (see below for original reply) but your pointer to look at the rk356x.dtsi now has me a little unsure that I have done this correctly.

Extracting the snippet for SPI3 shows that both CS0 and CS1 are already defined in the dtsi, so do then I assume that once the status for SPI3 changes from disabled to okay, both CS0 and CS1 pins are treated by the CPU as handling chip select functions. As in, I cannot use the CS1 pin for something else if SPI3 is enabled.

I also don't have to create two "spidevs" for each cs# pin etc.

Code:

spi3: spi@fe640000 {
  compatible = "rockchip,rk3568-spi", "rockchip,rk3066-spi";
  reg = <0x0 0xfe640000 0x0 0x1000>;
  interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
  clocks = <&cru CLK_SPI3>, <&cru PCLK_SPI3>;
  clock-names = "spiclk", "apb_pclk";
  dmas = <&dmac0 26>, <&dmac0 27>;
  dma-names = "tx", "rx";
  pinctrl-names = "default";
  pinctrl-0 = <&spi3m0_cs0 &spi3m0_cs1 &spi3m0_pins>;
  #address-cells = <1>;
  #size-cells = <0>;
  status = "disabled";
};

ORIGINAL REPLY:

I have got it setup using cs0 (i.e. using just a single cs). I've also created a script to bind the spidev to spi3.0 at boot up.

Code:

/dts-v1/;
/plugin/;

/ {
        fragment@0 {
                target = <&spi3>;

                __overlay__ {
                        status = "okay";
                        #address-cells = <1>;
                        #size-cells = <0>;

                        spidev@0 {
                                compatible = "spidev";
                                status = "okay";
                                reg = <0>;
                        }; 
                };
        };         
};

[gogerriko]

I worked out the solution and I provided an update here: https://github.com/Plebian-Linux/quartz6.../issues/32