linux-stable.git/drivers/spi, branch linux-2.6.24.y

atmel_spi: fix clock polarity

2008-03-24T18:47:32+00:00

commit: f6febccd7f86fbe94858a4a32d9384cc014c9f40

The atmel_spi driver does not initialize clock polarity correctly (except for
at91rm9200 CS0 channel) in some case.

The atmel_spi driver uses gpio-controlled chipselect.  OTOH spi clock signal
is controlled by CSRn.CPOL bit, but this register controls clock signal
correctly only in 'real transfer' duration.  At the time of cs_activate()
call, CSRn.CPOL will be initialized correctly, but the controller do not know
which channel is to be used next, so clock signal will stay at the inactive
state of last transfer.  If clock polarity of new transfer and last transfer
was differ, new transfer will start with wrong clock signal state.

For example, if you started SPI MODE 2 or 3 transfer after SPI MODE 0 or 1
transfer, the clock signal state at the assertion of chipselect will be low.
Of course this will violates SPI transfer.

This patch is short term solution for this problem.  It makes all CSRn.CPOL
match for the transfer before activating chipselect.  For longer term, the
best fix might be to let NPCS0 stay selected permanently in MR and overwrite
CSR0 with to the new slave's settings before asserting CS.

Signed-off-by: Atsushi Nemoto 
Acked-by: Haavard Skinnemoen 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

spi: pxa2xx_spi clock polarity fix

2008-03-24T18:47:22+00:00

commit: b97c74bddce4e2c6fef6b3b58910b4fd9eb7f3b8

Fixes a sequencing bug in spi driver pxa2xx_spi.c in which the chip select
for a transfer may be asserted before the clock polarity is set on the
interface.  As a result of this bug, the clock signal may have the wrong
polarity at transfer start, so it may need to make an extra half transition
before the intended clock/data signals begin.  (This probably means all
transfers are one bit out of sequence.)

This only occurs on the first transfer following a change in clock polarity
in systems using more than one more than one such polarity.  The fix
assures that the clock mode is properly set before asserting chip select.

This bug was introduced in a patch merged on 2006/12/10, kernel 2.6.20.
The patch defines an additional bit in: include/asm-arm/arch-pxa/regs-ssp.h
for 2.6.25 and newer kernels but this addition must be made in:
include/asm-arm/arch-pxa/pxa-regs.h for kernels between 2.6.20 and 2.6.24,
inclusive

Signed-off-by: Ned Forrester 
Signed-off-by: David Brownell 
Cc: Russell King 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[chrisw@sous-sol.org: backport to 2.6.24.3]
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

spi: omap2_mcspi PIO RX fix

2008-01-24T22:06:44+00:00

Before transmission of the last word in PIO RX_ONLY mode rx+tx mode
is enabled:

	/* prevent last RX_ONLY read from triggering
	 * more word i/o: switch to rx+tx
	 */
	if (c == 0 && tx == NULL)
		mcspi_write_cs_reg(spi,
				OMAP2_MCSPI_CHCONF0, l);

But because c is decremented after the test, c will never be zero and
rx+tx will not be enabled. This breaks RX_ONLY mode PIO transfers.

Fix it by decrementing c in the beginning of the various I/O loops.

Signed-off-by: Kalle Valo 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

spi_bitbang: always grab lock with irqs blocked

2008-01-09T00:10:35+00:00

Fix a glitch reported by lockdep in the spi_bitbang code: it needs to
consistently block IRQs when holding that spinlock.

Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

atmel_spi: reload RCR before TCR

2007-12-11T03:43:55+00:00

We have a wifi module connected to the spi bus and got sometimes FIFO
overrun errors on the spi bus.

After some investigation i found that the driver loads the TCR (transmit
count) register before the RCR (receive count).  When the transfer list is
not empty the atmel_spi_next_message is called while tx and rx are enabled.
 As soon as the TCR is loaded, hardware starts transfer and causes a rx
fifo overrun because the RCR is not loaded yet.

Load the RCR before the TCR.  After this patch the fifo overrun disapears
at out setup.

Signed-off-by: Haavard Skinnemoen 
Signed-off-by: Rini van Zetten 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

spi_imx: fix typo in description

2007-12-11T03:43:55+00:00

Signed-off-by: Will Newton 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

spi_bfin5xx: fix typo in description

2007-12-11T03:43:55+00:00

Signed-off-by: Will Newton 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

pxa2xx_spi: fix typo in description

2007-12-11T03:43:54+00:00

Signed-off-by: Will Newton 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Blackfin SPI driver: reconfigure speed_hz and bits_per_word in each spi transfer

2007-12-05T17:21:20+00:00

 - reconfigure SPI baud from speed_hz of each spi transfer
 - according to spi_transfer.bits_per_word to reprogram register and setup
   correct SPI operation handlers

Signed-off-by: Bryan Wu 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Blackfin SPI driver: move hard coded pin_req to board file

2007-12-05T17:21:20+00:00

Remove some sort of bloaty code, try to get these pin_req arrays built at compile-time

 - move this static things to the blackfin board file
 - add pin_req array to struct bfin5xx_spi_master
 - tested on BF537/BF548 with SPI flash

Signed-off-by: Bryan Wu 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds