No SPI MOSI on a LS1021A

[JamesBaker]

Hi,

I am trying to implement an SPI kernel driver on a TQMLS102xA module which uses an LS1021A.

The driver requires a single interface to user space and a single SPI interface that drives two SPI slaves. This mimics previous hardware solutions where a single user-space source of data is transmitted out to two networks, and received data from both networks is "combined" and passed on to user space.

CS0# and CS1# are used to select the slave(s) and IRQ's 4 & 5 to indicate newly received data (IRQ's yet to be implemented fully). SPI1 is used on the LS1021A.

To do this, I took spidev and created my own driver outside of the kernel. This sits on top of the FSL DSPI controller driver. It is based on spidev with additional task-specific code.

THE ISSUE:

The user-space app connects to the driver fine, but when transmitting data the correct CSx# line is driven low and the clock appears on SPI1_SCK but no data appears on MOSI (SPI1_SOUT).

I am using TQ's ptxdist build environment with Linux 4.14.78 for the target. I have configured the RCW correctly (as far as I can tell):

0608000a 00000000 00000000 00000000

FF000000 00CC7900 40025a00 21046000

00000000 00000000 00000000 0043c800

20124900 101b1340 00000000 00000000

DWORD 13, bits 402-404:   IFC_GRP_G_EXT = 001b -> SPI.
Decoded: xxxx 49xx -> 0100 1001 = 001 = SPI enabled inc. SPI1_SOUT.

Starting with the device tree, I am using the default ls1021a.dtsi with:

...

dspi0: dspi@2100000 {
compatible = "fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x2100000 0x0 0x10000>;
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "dspi";
clocks = <&clockgen 4 1>;
spi-num-chipselects = <6>;
big-endian;
status = "disabled";
};

...

And then adding my own dtsi on top with:

...

&dspi0 {
bus-num = <0>;
status = "okay";

darcnet0: darcnet@0{
compatible = "company,darcnet"; //device name : this name is used match a driver to the device
reg = <0>;
spi-max-frequency = <1000000>;
};

...

Obvs I can't post all the code here at this time, so I have condensed the driver as attached - if there is something that is missing/needs clarifying, please let me know! Just to obfuscate things, the code is written with CamelCase rather than the usual Linux snake_case.

[JamesBaker · Accepted solution]

Another post that appears it may offer a software solution but I'm afraid it just highlights that it is not always what you are doing that is the issue.

The problem is solved - a hardware issue on a "yes of course it is working fine" PCB meant the signal was not getting through. Thanks for looking.

[JamesBaker]

Hi Yipingwang,

I in fact did this the end of last week, and do get the node /dev/spidev0.0. Echo'ing data from the command line (e.g. echo "Hello" > /dev/spidev0.0) had the same result. The chip select works as does the clock, but again no data out.

I did discover another interesting fact, that if I leave the input floating, the driver appears to read in '0xFF' - but when the MISO is pulled low, such as through connecting it directly to the MOSI to attempt loopback, it reads in '0x00'. This implies that the module is probably reading in data OK - do you agree?

So it just doesn't transmit data.

Another thought is that I am not using DMA** - should I be? I took the spidev driver as a working example but was this a mistake?

** In my kernelconfig, I have CONFIG_HAS_DMA=y

[yipingwang]

&dspi0 {
                          bus-num = <0>;
                          status = "okay";

                          darcnet@0 {
                          compatible = "rohm,dh2228fv";
                          reg = <0>;
                          spi-max-frequency = <1000000>;
                         };
                    };

 With the above dts, please check whether you can get the node /dev/spidev0.0, whether you can see traffic on SPI.