Questions on example driver on eCSPI on MX53

[michaeljohn]

I've been looking at the mxc_m25p80.c example driver Freescale has for communicating on the eCSPI. I'm trying to write a driver for the Fujitsu mb85rs256 FRAM on a custom board with Linux 2.6.35. I can write and read 32-bits at a time with success, but when I implemented burst mode like in the example driver I've ran into issues.

In the example driver, Freescale has written there own function to call the kernel functions for SPI. Freescale called it spi_read_write. Why did Freescale not use a function provided by the kernel (spi_write, spi_read, spi_write_read)?

Also this function does some things I don't understand. They take the length of the byte array and shift it to the left 3 places, and set this as the bits_per_word. Why wouldn't this be the bits_per_word that the slave device expects? They then take the length of the byte array, add 3 to it, divide by 4 and set that as the length of the tx/rx buffer. Why? It's not clear why the Freescale driver is doing this. From what I've gathered it seems bits_per_word is really set to the number of bits in the FIFO and length is really how many levels of the FIFO are used.

Here is the snippet of code for reference:

static inline int spi_nor_setup(struct spi_device *spi, u8 bst_len)
{
     spi->bits_per_word = bst_len << 3;

     return spi_setup(spi);
}

#define     SPI_FIFOSIZE          24     /* Bust size in bytes */

static int spi_read_write(struct spi_device *spi, u8 * buf, u32 len)
{
     struct spi_message m;
     struct spi_transfer t;

     if (len > SPI_FIFOSIZE || len <= 0)
          return -1;

     spi_nor_setup(spi, len);

     spi_message_init(&m);
     memset(&t, 0, sizeof t);

     t.tx_buf = buf;
     t.rx_buf = buf;
     t.len = (len + 3) / 4;

     spi_message_add_tail(&t, &m);

     if (spi_sync(spi, &m) != 0) {
          printk(KERN_ERR "%s: error\n", __func__);
          return -1;
     }

     DEBUG(MTD_DEBUG_LEVEL2, "%s: len: 0x%x success\n", __func__, len);

     return 0;

}

Another thing I found odd was the order the tx buffer is filled with data to be transmitted. Rather than writing linearly to the byte array it writes in the index order of 3,2,1,0,7,6,5,4,11,10,9,8 .... is this due to how the eCSPI reads the FIFO? (32bit wide, 8 levels deep)

I've written a driver for this same FRAM on a platform with a TI am3352 and it was pretty straight forwards to get it working. Looking at this example driver for the MX53 I'm confused on why Freescale did what they did. Any help would be greatly appreciated.

Thanks.

Original Attachment has been moved to: mxc_m25p80.c.zip

[b36401]

It is only example driver provided for the reference.
Sorry for the inconvenience.

Have a great day,
Victor

[michaeljohn]

Hi Victor,

I eventually  got my driver to work once I ignored the example driver and implemented my driver following the spec in the Tech Reference. I found there were many contradictions to what was is the spec versus what the example driver implemented.

-Michael

[TomE]

I had a lot of trouble with SPI too. The driver has problems detailed here:

i.MX53 i.MX51 SPI 8 bit mode only, No GPIO CS & Baud Rate 

That's not the only problem I had with it. It stopped sending a data stream when the CPU idled because the power controls were set up wrongly in the platform code:

i.MX53 eCSPI Stops Sending when CPU Idles 

As you're using 2.6.35, you might like to look at all the other patches I've had to make to the OS to get it working properly. For instance, the GPIO pins configuration code is broken, the Ethernet driver doesn't support IPV6 (or any multicasts), the CAN driver can't receive or send packets in order and other problems. Most of them are summarised here, some as pointers to other posts:

Submit i.MX53 & i.MX28 Linux kernel patches 

The PWM glitches badly on duty cycle change, in my case causing bright flashes of the LCD backlight:

i.MX53 (also i.MX6) PWM Glitches on Duty Cycle Change 

The OCRAM is documented as being "one clock access", but that clock seems to run 120 times SLOWER than the CPU Clock! That\'s better than the GMEM used to talk to the GPU as that's 250 times slower. That also explains the NAND read speed, which is also bottle-necked through some slow RAM in the controller.

https://community.nxp.com/thread/355199 

Tom