[#5877] SPI transmit cs_change flag not properly handled
Submitted By: Rob Maris
2010-02-02 07:20:07 Close Date
Closed Fixed In Release:
Found In Release:
ALL Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
Toolchain version or rev.:
App binary format:
Summary: SPI transmit cs_change flag not properly handled
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.
--- 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:
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
--- Barry Song 2010-06-04 02:43:37
patch applied. close it.
File Name File Type File Size Posted By
diff application/octet-stream 655 Rob Maris