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