[#3823] spi transaction has too many delays

Submitted By: Larry Samuels

Open Date

2008-01-10 07:10:24 Close Date

2008-01-19 07:12:24

Priority:

Medium Assignee:

Bryan Wu

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

linux 2.6.x

Category:

Drivers Board:

STAMP

Processor:

BF537 Silicon Revision:

0.3

Is this bug repeatable?:

Yes Resolution:

Rejected

Uboot version or rev.:

Toolchain version or rev.:

App binary format:

N/A

Summary: spi transaction has too many delays

Details:

Using the spidev.c and spi_bfin5xx.c drivers, the transfer has delays which slows the maximum SPI thruput.

I configured the stamp.c file to use the spidev.c driver file, and chips select 2 as follows:

#if defined(CONFIG_SPI_SPIDEV) || defined(CONFIG_SPI_SPIDEV_MODULE)

static struct bfin5xx_spi_chip spidev_chip_info = {

.enable_dma = 0,

.bits_per_word = 8,

.cs_change_per_word = 0,

};

#endif

...........

#if defined(CONFIG_SPI_SPIDEV) || defined(CONFIG_SPI_SPIDEV_MODULE)

{

.modalias = "spidev",

.max_speed_hz = 6250000, /* max spi clock (SCK) speed in HZ

.bus_num = 0,

.chip_select = 2,

.controller_data = &spidev_chip_info,

.mode = SPI_MODE_1,

#endif

I add a pullup resistor to CS2 line.

Thie signal goes low before the 3 byte transmission, and then goes high

after the 3 bytes as it should. So that is working.

The problem is if I send consecutive messages, each message takes 83 usec

to transmit.

For each message:

After CS goes low, the 1st SCLK pulse appears 29 uSec later.

After the last SCLK pulse, CS goes high in 8.8 uSec

The next message CS goes low 38 uSec after that.

The portion of the message where SCLK runs is 10 uSec

So I'm losing 73 uSec of throughput every message.

The SPI delays need to be elminiated to increase throughput.

Follow-ups

--- Bryan Wu 2008-01-11 04:30:04

Thanks Larry, I am working on it.

-Bryan Wu

--- Bryan Wu 2008-01-15 21:55:22

Hi Larry,

Actually, this is a performance issue.

Currently, Linux kernel SPI common framework which Blackfin SPI depends on is

using workqueue/tasklet. This implementation will introduces some delay because

the tasks is scheduled by Linux kernel scheduler.

So for some critical real-time or performance SPI transfer requirement, you may

not use the SPI framework. Please refer to SPI_MMC driver which using directly

SPI operation: drivers/mmc/spi_mmc/bfin_pio_spi.c

Thanks

-Bryan Wu

--- Larry Samuels 2008-01-16 15:17:08

Bryan,

I agree, the Linux task scheduler can effect the queueing of messages and

create delays using the spi_dev.c implmentation.

Since this is not really a bug, then close out this bug as resolved.

I will look at the mmc spi implmentation, and write a driver from scratch.

Thanks again,

Larry

--- Bryan Wu 2008-01-19 09:14:13

Thanks a lot for your understanding.

-Bryan Wu

Files

Changes

Commits

Dependencies

Duplicates

Associations