This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

am3352: SPI block read issues

Part Number: AM3352


Hi, 

My customer writes:

Have a question regarding the AM335x SPI interface with a little background. 

We are using the SPI1 interface in “Master simultaneous Transmit & Receive mode” to interface to an FPGA. So, the MOSI and MISO lines are active at exactly the same time as the AM335x puts out the clock during the SPI transaction. This of course makes FPGA reads a bit challenging since data essentially has to be ready as soon as the SPI transaction starts, so I’ve been playing around with different SPI speeds and SPI word bit lengths to build time into the cycle to be able to return read data in real-time. We had a lot of early  development problems with SPI (both H/W and Linux) on the past spin of the board, but now we’re cleaning things up and attempting to boost the performance quite a bit so we can speed up our network. 

Using Linux SPIDEV, we’ve been experimenting with SPI performance a bit and have been able to get SPI block writes to work for writing packets over SPI to the FPGA, but we were unable to get SPI block reads to work, which I think makes sense after thinking about it since read data back to the AM335x over the MISO line must be driven concurrently by writes over the MOSI line since both lines are active together in Master TX/RX mode. Our Linux Firmware Eng. has indicated that there exists some sort of simultaneous block read/write capability that could address this; however, it is supported in Kernel version 4.1.18 which we have not gone to yet. 

So, I think what this looks like is the Firmware, during block reads, would have conduct a dummy block write in order to drive that read data back to the AM335x as a block read. This would seem to create a bottleneck in the SPI controller running block-type transactions simultaneously in both directions, but maybe it works.   

Question is, are we on the right track here on how to drive block reads from the FPGA over SPI? We don’t want to go too far down this path if there is a better way to boost performance of SPI in both directions. Would updating to the newer version of Linux solve this problem for us? 

Any suggestions about a Kernel migration or the best way to do block reads over SPI?

Thanks!  Blake

  • Hi Blake,

    The software team have been notified. They will respond here.
  • Blake,

    I will need to do some experiments after returning to the office next week, however, I do have a few questions:

    1) What kernel version is currently used?
    2) Looking at the kernel docs, it seems full duplex has been supported by spidev before 4.1.18 - is the issue spidev, or the TI driver?
    3) Does this [1] example code work, modified as described at the end of the spidev docs [2] for full duplex?

    Regards,
    Mike

    [1] elixir.free-electrons.com/.../spidev_fdx.c (note, this was found in /Documentation/spi in older kernels)
    [2] www.kernel.org/.../spidev
  • Hi Mike,

    See below from the customer:

    From one of our FW engineers who is working on the Linux code:

     Here are my answers: 

      1. 1.      The Kernel version is 3.12.10.
      2. 2.      Issue is with TI-Driver, CPU bumps up to 50% usage.
      3. 3.      Could not answer cause the references were missing…. [Blake:  My Fault - I have sent them after the fact] 

    In case of our block write we use “Write” system call instead of “IOCTL”. The write call in SPIDEV will internally invoke MCSPI API to write to OMAP2_MCSPI_TX0 Register. In this current kernel, DMA is disabled in compilation. 

    SPIDEV does support full-duplex, I would need your help to analyze the SPI signal on Teledyne. 

    To summarize and add … we’re looking to boost performance of SPI while in Master Tx/Rx mode and we think that requires code that utilizes the DMA engine and the internal SPI FIFO, most likely. Looking for TI to help us chart a path forward to accomplish that whether it is pointing us to newer code that supports this or if we have to make the feature additions ourselves.

    Thanks!

    Blake

  • Hi Blake,

    I'm seeing DMA engine support for MCSPI in kernel version 3.8, so I think it should be present in 3.12.

    The kernel docs for MCSPI has an example of reserving DMA channels: 

    This E2E thread provides some additional information as well: 

    Regards,
    Mike

  • The customer is going over this data at length. We may want to close this as I suspect it will be 2 - 3 weeks before he gets back with us.

    Thanks for your help!

    Blake