Questions on example driver on eCSPI on MX53

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 itspi_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.

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.

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.

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:

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.