[#4620] spi controller driver does not assert/deassert CS correctly

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

[#4620] spi controller driver does not assert/deassert CS correctly

Submitted By: Yi Li

Open Date

2008-11-06 23:30:13     Close Date

2008-12-02 02:13:01

Priority:

Medium     Assignee:

Yi Li

Status:

Closed     Fixed In Release:

N/A

Found In Release:

N/A     Release:

svn trunk

Category:

N/A     Board:

STAMP

Processor:

BF537     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

App binary format:

N/A     

Summary: spi controller driver does not assert/deassert CS correctly

Details:

 

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.

 

Follow-ups

 

--- Mike Frysinger                                           2008-11-07 00:39:50

if the hardware isnt working as expected, then we should contact

processor.support@analog.com ...

 

--- 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.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes