[#5877] SPI transmit cs_change flag not properly handled

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

[#5877] SPI transmit cs_change flag not properly handled

Submitted By: Rob Maris

Open Date

2010-02-02 07:20:07     Close Date

2010-06-04 02:46:04

Priority:

Medium     Assignee:

Barry Song

Status:

Closed     Fixed In Release:

N/A

Found In Release:

snaps     Release:

svn trunk

Category:

Drivers     Board:

STAMP

Processor:

ALL     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

2009R1-RC2

App binary format:

FDPIC     

Summary: SPI transmit cs_change flag not properly handled

Details:

 

Source code: drivers/spi/bf5xx-spi.c

 

Upon multibyte (full-duplex) transfer of messages via spidev device, a single cs_change set to 1, let us say in the middle of the message, all subsequent bytes are xmitted with cs steady inactive.

 

Cause: CS is set active only upon start of a message.

 

Attached patch file represents a simple solution. Note: an if (drv_data->cs_change) is outcommented now. It may be intended as a set cs active, when the change flag is 1, but for correct operation, it should test for the change flag of the previously sent byte!

The patch file represents a tested solution: when a single byte is associated with cs_change=1, cs will go high, and go low upon next byte.

 

Note: this is tested with delay_secs set to 0 as well as an arbitrary other value.

 

Follow-ups

 

--- Mike Frysinger                                           2010-02-02 12:09:51

your patch may fix behavior for the less common cs_change=1, but it certainly

breaks all of the much more common cs_change=0

 

if the wrong message cs_change is being checked, then that should be fixed

 

--- Barry Song                                               2010-03-29 00:21:28

Mike, I think Rob's patch is acceptable and will not destroy cs_change=0 for his

case. It will make sure CS is always low for one spi transfer no matter

cs_change is 1 or 0. But according to his logic, here should be commented too:

//if (!drv_data->cs_change)

                bfin_spi_cs_deactive(drv_data, chip);

 

But is there really a device using this kind of timing? some transfers use

cs_change=1, others use cs_change =0 in a single spi_message? I think a device

should use one mode and our driver has been programmed based on this

supposition.

 

-barry

 

 

 

--- Barry Song                                               2010-06-04 02:43:37

patch applied. close it.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

diff    application/octet-stream    655    Rob Maris

Attachments

Outcomes