Re: [PATCH 3/5] dw_spi: rework message processing

From: Dirk Brandewie
Date: Thu Jun 16 2011 - 15:52:38 EST

On 06/16/2011 10:38 AM, Grant Likely wrote:
On Thu, Jun 16, 2011 at 11:28 AM, Dirk Brandewie
<dirk.brandewie@xxxxxxxxx> wrote:
On 06/16/2011 07:00 AM, Feng Tang wrote:

4. I saw you enable both TX/RX interrupt when doing interrupt transfer,
devices' TX/RX are born to be simutaneous, when one word is sent over
TX line, a RX word will be received from RX line, so both the orignal
interrupt transfer handling written by me and the later optimization
from Alek Du only enable TX interrupt, which will only generate half of
IRQs comparing to enble both TX/RX, this is huge when the data rate is
several Mb per second

I the current driver the txfltr register is set to 0 (FIFO empty) in the
interrupt transfer case which will drop chip select every FIFO length bytes.

In my transfer setup the RX FIFO interrupt is set to a value lower than the
TX threshold which will keep both interrupts from firing at the same time.

The TX interrupt will drive the transfer until there are less than
tx_threshold bytes left to transfer then by the RX interrupt to drive the
remainder of the transfer without dropping chip select.

Be careful here. Can you guarantee that the kernel will process the
IRQ before the FIFO drains? If not, then you'll need something more

I can't guarantee when IRQ are processed :-)

Without actual control over when chip is de-asserted I don't think we guarantee that chip select will be not dropped, chip select is dropped when the TX fifo goes empty.

With a sufficiently high bitrate client, heavily loaded system and fixed size fifo we are domed at some point. As tx_threshold approaches fifo depth you give yourself a bigger buffer in time but increase the number of interrupts you need to deal with increasing the system load.

For high bitrate devices the client driver should be using DMA IMHO to work around this limitation in the designware IP. Of course this doesn't solve the problem of chip select dropping between transfers in the same message.

I took a SWAG at tx_threshold in my changes to try to limit the number of interrupts it will need tuning for a reasonable default and likely the addition of a module parameter or platform data to set it for any given SOC/system.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at