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.

OMAP McSPI CS stays low for 120usec after DMA transfer



Hello,

I am testing some data throughput on the McSPI1 on the OMAP 3530.  When using DMA to transfer a 160 byte message I notice on the scope that the chip select line stays low for the entire transfer which is what I expect using the latest Linux kernel since force_cs is being used.  However when the transfer is completed and the clock stops I notice that the CS line is still low for around 120usecs.  I have tried different OMAP setups using 90Kbyte transfers and anything above 8 bytes to make sure I am using DMA, and this appears to happen all the time.

In my case since it takes 130usecs to transfer the 160bytes I have to wait the same amount of time to let the CS come up before I can transfer another 160bytes.  I am curious if this is something that is standard with the SPI controller on the OMAP?

I dont see anything in the TRM about this and would really like to see if I can get this delay to disappear if possible.

Thanks,

Brian

  • Hello Brian Austin,

    As I see from you post above that you have got SPI Slave interface working. I've been working on the same. I've beagleboard Rev C3, and 'm facing problems configuring pin MUXing for SPI slave interface.

    To be precise, my problem is i'm using linux-omap 2.6.29 kernel version and I see that we have omap_ctrl_writew(This writes in the lower 16bits of the register, upper 16bit padded with ZEROs) has been used for setting up the pins for other devices. However, from the TRM, I understand that for configuring SPI slave interface on the external pin, i've to write into upper 16bits of atleast 2 registers. For this if i use omap_ctrl_writel(which writes to 32bits of the register), i'm getting alignment execption(0x801) at X(addr).

    Really appreciate your help on this.

    Thanks.