mxs/spi: Add SPI slave mode operation DT prop

This allows user to select the slave mode of operation of the controller. This is by no means standard, see the binding documentation for details, there is plenty of them. Sadly, such knowledge is not provided in the chip documentation. Hopefully, this mode of operation might come useful for people who do know very well what they are doing, otherwise this should never be touched.

This allows user to select the slave mode of operation of the controller. This is by no means standard, see the binding documentation for details, there is plenty of them. Sadly, such knowledge is not provided in the chip documentation. Hopefully, this mode of operation might come useful for people who do know very well what they are doing, otherwise this should never be touched.

On Thu, Aug 23, 2012 at 7:42 PM, Marek Vasut

Quoted 6 lines · <[email protected]> wrote:

This allows user to select the slave mode of operation of the controller. This is by no means standard, see the binding documentation for details, there is plenty of them. Sadly, such knowledge is not provided in the chip documentation. Hopefully, this mode of operation might come useful for people who do know very well what they are doing, otherwise this should never be touched.

Thanks for posting this, as it's something I'm trying to get it working too.

You're right that the Freescale documentation says almost nothing about slave mode. I found some STMP36xx on the rockbox site,
http://www.rockbox.org/wiki/pub/Main/SigmaTelSTMP3xxx/stmp36xx-Datasheet-1-
02_050306.pdf, however it doesn't provide any more information about slave mode than the imx28 RM. In fact it's virtually the same word for word, other than some bits that are marked reserved in the imx28 are defined in stmp36xx (wonder if the FIFO stuff is still there in the imx28?). What STMP36xx documentation did you find that had more information?

Documentation/devicetree/bindings/spi/mxs-spi.txt Required properties: · line 20

Quoted 3 lines

Documentation/devicetree/bindings/spi/mxs-spi.txt +3 -0

+		   - If the SPI master generates clock at n MHz, the speed
+		     of the SPI slave controller must be at least 4-8 times
+		     faster, this is due to the controller samples the CLK

When you say the SPI slave clock must be 4x higher than the master clock, do you mean the rate programmed for what would be the SPI clock in master mode: SSP_SCK in the HW_SSP_TIMING register. Or the rate of the clock to the SSP block: SSPCLK as programmed via the CLKCTRL block's registers, e..g. HW_CLKCTRL_SSP1?

Documentation/devicetree/bindings/spi/mxs-spi.txt Required properties: · line 27

Quoted 1 line

Documentation/devicetree/bindings/spi/mxs-spi.txt +1 -0

+		   - The DMA has to wait indefinitelly for the arriving data.

Is there a reason that this must be done? I'd guess that after the SSP is told to start a transfer in slave mode it waits for the master to assert the SSn line and begin the transfer. If the completion times out before this happens then it makes sense it wouldn't work. But does it still not work if the SPI transfer completes before the completion timeout? Or is this necessary because in your application there might be a long wait before the master chooses to initiate a transfer after you program it on the Linux side?

In my case I have a device that is mostly a SPI slave, except it wants to drive the clock itself, most unfortunately. It doesn't drive the slave select, rather the imx28 will still drive that (I assume I'll need to use a GPIO and loop it back to SSn to trick the SSP into thinking the "master" has asserted the slave select). So really, I'm doing SPI master transactions on the Linux side, but need to put the SSP into slave mode to get the clock right. This makes it quite a bit easier to do on Linux than a general slave mode, which is quite the can of worms. I tried creating an I2C slave mode framework for another application but was never happy with it. I imagine this is why no one has ever created a general spi slave framework for Linux.

Quoted 11 lines

On Thu, Aug 23, 2012 at 7:42 PM, Marek Vasut

Quoted 1 line

+ - The DMA has to wait indefinitelly for the arriving data.

Is there a reason that this must be done? I'd guess that after the SSP is told to start a transfer in slave mode it waits for the master to assert the SSn line and begin the transfer. If the completion times out before this happens then it makes sense it wouldn't work. But does it still not work if the SPI transfer completes before the completion timeout? Or is this necessary because in your application there might be a long wait before the master chooses to initiate a transfer after you program it on the Linux side?

The problem is the SPI block in slave mode ignores SS being pulled back up.

Quoted 2 lines

another application but was never happy with it. I imagine this is why no one has ever created a general spi slave framework for Linux.

SPI slave is hard because you can not anticipate the amount of data you will receive. You can not anticipate when you will receive those either.

Quoted 14 lines

Quoted 5 lines

On Thu, Aug 23, 2012 at 7:42 PM, Marek Vasut

Quoted 2 lines

+ - The DMA has to wait indefinitelly for the arriving
data.

Quoted 8 lines

Is there a reason that this must be done? I'd guess that after the SSP is told to start a transfer in slave mode it waits for the master to assert the SSn line and begin the transfer. If the completion times out before this happens then it makes sense it wouldn't work. But does it still not work if the SPI transfer completes before the completion timeout? Or is this necessary because in your application there might be a long wait before the master chooses to initiate a transfer after you program it on the Linux side?

Quoted 2 lines

The problem is the SPI block in slave mode ignores SS being pulled back up.

I've setup a board with a spi-gpio port looped to a spi-mxs port in slave mode so I can test this. I did not need to change the DMA timeout to get it to work. If the master does not send enough within the SSP timeout the slave transaction will timeout. It does not seem to ignore SS, but rather the DMA will not finish until all the requested words are received, no matter how many SS pulses that happens to take. For general purpose slave support it would of course be nice to be able to end the message when the master drops SS, but the SSP either doesn't support this or a different technique is needed.

I've found that if PHASE = 0, the SSP expects the SS to be pulsed high between each word (w/ current driver, word == 8 bits). This is slightly alluded to in the imx28 manual, where the PHASE = 0 descriptions in sections 17.5.3 and 17.5.5 contain, "... in the case of continuous back-to-back transmissions, the SSn signal must be pulsed high between each data word[.]" While for the PHASE = 1 descriptions in sections 17.5.4 and 17.5.6 it says, "For continuous back-to-back transfers, the SSn pin is held low between successive data words[.]"

One would think this is talking about master mode like the rest of the section, but it seems to only apply to slave mode. In master mode one can easily produce a SPI signal without SS pulsed between each word with either phase setting.

Testing with the master TX sending 1 byte per SS asserted period:

$ echo abcd1234ABCDwxyz | dd of=/dev/spidev4.0 bs=1

Slave RX receives the first four bytes:

$ dd if=/dev/spidev2.0 count=1 bs=4 | hd
[  638.673625] spidev spi2.0: Start POL 0 PHA 0
00000000  61 62 63 64                                       |abcd|

Trying with 4 bytes per SS assertion:

$ echo abcd1234ABCDwxyz | dd of=/dev/spidev4.0 bs=4
$ dd if=/dev/spidev2.0 count=1 bs=4 | hd
00000000  61 31 41 77                                       |a1Aw|

The slave receives the first byte of each SS assertion pulse. If I change the protocol to PHASE=1, then this case works as well and I receive the first four bytes. I didn't need to set POLARITY to 1, just phase.

$ dd if=/dev/spidev2.0 count=1 bs=16 | hd
[  261.277000] spidev spi2.0: Start POL 0 PHA 1
$ echo abcd1234ABCDwxyz | dd of=/dev/spidev4.0 bs=4
00000000  61 62 63 64 31 32 33 34  41 42 43 44 77 78 79 7a 
|abcd1234ABCDwxyz|

The same thing happens if the bs for the master size is to 1, 2, 8, or
16. Setting it to another values like 3, 5, 32 doesn't work. Maybe the slave ignores extra SS pulses in the middle of a transfer, but will fail to complete the transfer if it doesn't get SS de-asserted at the end as expected?

Quoted 5 lines

Quoted 2 lines

another application but was never happy with it. I imagine this is why no one has ever created a general spi slave framework for Linux.

SPI slave is hard because you can not anticipate the amount of data you will receive. You can not anticipate when you will receive those either.

The same can be said for a serial UART or an ethernet MAC, yet those don't seem to be too hard.

I think the problem is that these devices
usually have things like FIFOs, IRQ trigger levels, pools of buffer descriptors, etc. that are designed to handle this. The design of slave mode in SPI and I2C controllers seems to be more of an afterthought, with none of the features one would except to deal with it. Also, the slave protocol design for things like EEPROMs often have nanosecond scale latencies that are nearly impossible to achieve in a general purpose CPU running a multitasking OS. No one would design a network protocol that requires an ACK packet within 10 ns of receiving a REQ, and expect the CPU to handle that. Yet that can be expected of a SPI EEPROM.

However, there are applications where one can predict what the master will do ahead of time and don't have these problems. In my case I know what and when the master will do something and can prime the SSP with a matching slave mode transaction before the master initiates. I know I'm not the first person who has needed to do this on Linux. So maybe it's worthwhile to add a limited slave support system without solving the problem of general purpose slave support.