[#5203] SPI driver fails to deactive chipselect in SPI_MODE_3
Submitted By: Barry Song
Open Date
2009-06-03 21:59:49 Close Date
2009-07-17 05:30:50
Priority:
Medium Assignee:
Barry Song
Status:
Closed Fixed In Release:
N/A
Found In Release:
N/A Release:
Category:
Drivers Board:
N/A
Processor:
BF537 Silicon Revision:
Is this bug repeatable?:
Yes Resolution:
Fixed
Uboot version or rev.:
Toolchain version or rev.:
2009R1-RC6
App binary format:
N/A
Summary: SPI driver fails to deactive chipselect in SPI_MODE_3
Details:
AD1938 is using SPI_SSEL5, which is also a pin-mux of GPIO_PF5. But I only can set it as GPIO to make chipselection work normally in SPI_MODE_3.
Code1 defines the pin as chipselect belong to SPI controller:
static struct bfin5xx_spi_chip ad1938_spi_chip_info = {
.enable_dma = 0,
.bits_per_word = 8,
};
static struct spi_board_info bfin_spi_board_info[] __initdata = {
...
{
.modalias = "ad1938-spi",
.max_speed_hz = 3125000, /* max spi clock (SCK) speed in HZ */
.bus_num = 0,
.chip_select = CONFIG_SND_BLACKFIN_SPI_PFBIT, /* #define CONFIG_SND_BLACKFIN_SPI_PFBIT 5 */
.controller_data = &ad1938_spi_chip_info,
.mode = SPI_MODE_3,
},
…
}
Code2 defines the pin as GPIO to simulate chipselect by software:
static struct bfin5xx_spi_chip ad1938_spi_chip_info = {
.enable_dma = 0,
.bits_per_word = 8,
.cs_gpio = GPIO_PF5,
};
static struct spi_board_info bfin_spi_board_info[] __initdata = {
...
{
.modalias = "ad1938-spi",
.max_speed_hz = 3125000, /* max spi clock (SCK) speed in HZ */
.bus_num = 0,
.chip_select = 0, /* use GPIO cs */
.controller_data = &ad1938_spi_chip_info,
.mode = SPI_MODE_3,
},
…
}
Code2 works(the pin will become high after transferring), but chipselect is always low in code1.
After a simple debug, I found in code1 mode,
1. SPI driver requests the chipselect 5 indeed, since the peripheral_request() function is called
2. the SPI driver writes registers to deactive the chipselect for every transfer indeed,since bfin_spi_cs_deactive() and write_FLAG() are called.
But the deactive operations can't make the pin high in fact.
Follow-ups
--- Yi Li 2009-06-04 05:00:30
Is it possible some jumper not set correct?
--- Barry Song 2009-06-05 00:32:13
Those jumpers should be connected right since AD1938 can work when configing as
GPIO. GPIO and SPI_CS are using the same pin and external line. Configing as
GPIO or SPI_CS is a behavior in software.
--- Steve Strobel 2009-06-11 12:51:45
Just a couple of notes that may or may not be helpful: I am using SPI_MODE_0
rather than SPI_MODE_3 with an AD1938. I can't comment on the chip select going
high after a transfer because I am using the bitbang driver for that device.
I did have some trouble with hardware-controlled SPI chip select lines (two of
them going active at the same time) as described in
That issue is reportedly fixed, so it probably isn't relevant.
Steve
--- Yi Li 2009-06-11 23:29:34
Barry,
Could you try SPI_MODE_0?
--- Barry Song 2009-06-12 00:34:55
Check http://docs.blackfin.uclinux.org/doku.php?id=spi, using SPI_MODE_0, CS
will be deactive every 8bit in my case. It is not useful to AD1938.
--- Barry Song 2009-06-17 06:14:11
Original codes misunderstand the meaning of SPI Flag Register (SPI_FLG). In
fact, no matter we want to de-active or active one chipselect, we must
"FLSx SPISSELx enabled", then "FLGx".
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found