Last steps for direct spi register access

Hello everyone it’s that time again,

Like a previous post about a faster way to access the GPIO (what succeeded) I also would like to speed up the access time to the SPI. For the full picture, I already have tried (and that works) to send something via the /dev/spidev0.0. Only in my opinion I find it rather slow, so i’m starting to access the SPI registers directly (mmap with /dev/mem).
I’m nearly there (get the correct register with content, also able to change those settings) but I have one or two hick ups that I cant find which prevent me to send something. It’s the following where I get stuck:

If I read the manual correctly is that after setting up the ECSPI with the correct configuration that I like (I’m cheating here and use the default configuration that is set bij /dev/spidev0.0), I only have to fill TXFIFO and set the XCH bit. After setting the XCH bit it would send the data out, this I do with the following:

	spi_pointer[0][0x01] = 0xAAAAAAAA; //Fill TXFIFO register with a word
	spi_pointer[0][0x02] |= 0x4; set XCH bit
	while(((spi_pointer[0][0x02]>>2) & 1) == 1); wait until XCH is low

spi_pointer[0][0x01] points to Transmit Data Register (ECSPI1_TXDATA).
spi_pointer[0][0x02] points to Control Register (ECSPI1_CONREG).

But after setting the XCH bit, I dont see any output on the SPI CLK (which I see when using the default /dev/spidev0.0). I also have check the IOMUX registers and they are still set for SPI. The SPI configurations are also still the same after I send my own data through my routine.
Also in ECSPI1_TESTREG you should see how many bites are ready which are put in the TXFIFO, but I always see zero here. So my guess would be that I don’t write data to the TXFIFO, but I follow the steps in the manual. So I don’t know where it’s going wrong. Is there something dumb I’m doing without noticing it?

I’m not asking for ready to use code but hint are welcome, imaging that you also could had problems with this.

Kind regards,

Remco

We at Toradex do not support such weird ways of trying to do things. Rather than complaining about latency or speed and hacking up something like you did it would be better to understand what may be wrong in how you tried it and what optimisation one could maybe do. E.g. spidev is absolutely not meant for high speed accesses but rather for easy user space style prototyping or in case performance does not matter so much. In-kernel device type specific drivers/stacks are usually preferred. However you fail revealing what exactly you are attempting to do from a system perspective.

As a hint DMA SPI configuration may interfere with the way you hacked up things but that’s just a guess.