pavel-demin / red-pitaya-notes

Notes on the Red Pitaya Open Source Instrument
http://pavel-demin.github.io/red-pitaya-notes/
MIT License
337 stars 209 forks source link

SPI Bus Enumeration - spidev2.0 why not spidev1.0? #321

Closed ghost closed 8 years ago

ghost commented 8 years ago

The SPI example - http://redpitaya.com/examples-new/spi/ works after replacing spidev1.0 with spidev2.0. I had a few more questions, and this might seem a bit pedantic, but I am seeking to understand.

I was a little confused about the bus enumeration. Last week I was trying to figure what was actually coming out on the expansion headers of the Red Pitaya since it was labelled SPI1 on the schematics but the SPI user space device is enumerated as spidev2.0 ... Naturally this got my brain in a knot (which happens easily).

spidev2.0 is SPI device identifier 2 and chipselect number 0 ( /dev/spidevB.C , where B is the SPI device identifier and C is the chipselect number). This is all fine and good, but why is not enumerated as spidev1.0, which would be more consistent with the schematic diagram?

I just want to understand the rationale for the enumeration spidev2.0 ... From the Red Pitaya forum, I learned SPI0 is deactivated on the Red Pitaya "SPI0 used to be mapped to EMIO in the older (<0.94) versions, but there was never anything connected to it in the PL" ... and I think there was a patch on the stock OS to do spidev1.0 ... I think the new enumeration comes from the aliases that were defined in the Device Tree:

The zynq include dts "zynq-7000.dtsi" says this:

                spi0: spi@e0006000 {
                        compatible = "xlnx,zynq-spi-r1p6";
                        reg = <0xe0006000 0x1000>;
                        status = "disabled";
                        interrupt-parent = <&intc>;
                        interrupts = <0 26 4>;
                        clocks = <&clkc 25>, <&clkc 34>;
                        clock-names = "ref_clk", "pclk";
                        #address-cells = <1>;
                        #size-cells = <0>;
                };

                spi1: spi@e0007000 {
                        compatible = "xlnx,zynq-spi-r1p6";
                        reg = <0xe0007000 0x1000>;
                        status = "disabled";
                        interrupt-parent = <&intc>;
                        interrupts = <0 49 4>;
                        clocks = <&clkc 26>, <&clkc 35>;
                        clock-names = "ref_clk", "pclk";
                        #address-cells = <1>;
                        #size-cells = <0>;
                };

The system.dts says this:


                aliases {
                        ethernet0 = &gem0;
                        serial0 = &uart0;
                        serial1 = &uart1;
                        spi0 = &qspi;
                        spi1 = &spi0;
                        spi2 = &spi1;
                };

Thanks for any help clarifying this design.

pavel-demin commented 8 years ago

I think that you've already answered your question. Looks like the following lines rename spi1 to spi2:

aliases {
  ...
  spi2 = &spi1;
  ...
}

I don't know why the Xilinx developers decided to include the aliases for the SPI devices. Personally, I don't see anything wrong with them.

If for some reason your project requires spidev1.0, then editing system.dts should be easy. For my projects I'm using the following patch file to modify system.dts: https://github.com/pavel-demin/red-pitaya-notes/blob/master/patches/devicetree.patch

ghost commented 8 years ago

Thank you for the reply Pavel, I think my curiosity was more about understanding the rationale behind this convention. If needed I will edit my Device Tree.