[#4620] spi controller driver does not assert/deassert CS correctly
Submitted By: Yi Li
2008-11-06 23:30:13 Close Date
Closed Fixed In Release:
Found In Release:
BF537 Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
Toolchain version or rev.:
App binary format:
Summary: spi controller driver does not assert/deassert CS correctly
This bug can be observed when two SPI devices are sharing the spi bus:
One device is set as SPI CS 7, another one is using SPI CS 4.
In spi_bfin5xx.c: cs_active(), cs_deactive() are used to control SPI_FLG register. From the debug bellow:
cs_active: flag: 0x7f91, chip->flag: 0x7f80, cs: 7
cs_active: flag: 0xef91, chip->flag: 0xef10, cs: 4
When device A (cs_7) activate CS 7, SPI_FLG is set as 0x7f91 (however, SPI_FLG should be set as 0x7f80, or 0x6f91 if in broadcast mode).
Due to some HW bug (very possibly), if SPI_FLG is set as 0x7f91, SPISSEL7 is asserted, however SPISSEL4 will be asserted too (I can see this using the scope). This is unreasonable according to HRM.
--- Mike Frysinger 2008-11-07 00:39:50
if the hardware isnt working as expected, then we should contact
--- Yi Li 2008-11-07 00:56:33
Fixed on trunk.
--- Yi Li 2008-11-10 02:34:19
Reading the comments in include/linux/spi/spi.h regarding to struct
spi_transfer.cs_change, I think current code in spi_bf5xx.c is not correct:
* All SPI transfers start with the relevant chipselect active. Normally
* it stays selected until after the last transfer in a message. Drivers
* can affect the chipselect signal using cs_change.
* If the transfer isn't the last one in the message, this flag is
* used to make the chipselect briefly go inactive in the middle of the
* message. Toggling chipselect in this way may be needed to terminate
* a chip command, letting a single spi_message perform all of group of
* chip transactions together.
* (ii) When the transfer is the last one in the message, the chip may
* stay selected until the next transfer. On multi-device SPI busses
* with nothing blocking messages going to other devices, this is just
* a performance hint; starting a message to another device deselects
* this one. But in other cases, this can be used to ensure correctness.
* Some devices need protocol transactions to be built from a series of
* spi_message submissions, where the content of one message is determined
* by the results of previous messages and where the whole transaction
* ends when the chipselect goes intactive.
--- Yi Li 2008-12-02 02:13:01
fixed and close.
File Name File Type File Size Posted By
No Files Were Found