[#3823] spi transaction has too many delays

Document created by Aaronwu Employee on Aug 28, 2013
Version 1Show Document
  • View in full screen mode

[#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

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes