The SPI core now expects num_chipselect to be set correctly as due to added
checks on the chip being selected before an transfer is allowed. This patch
adds a num_cs field to the platform data which needs to be set correctly
before adding the SPI platform device.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The s3c24xx_spi_txrx() function should initialise the completion each time
before using it, otherwise we end up with the possibility of returning success
before the interrupt handler has processed all the data.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since 43cc71eed1, the platform modalias is
prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable SPI
platform drivers, to allow module auto loading.
[dbrownell@users.sourceforge.net: more drivers: registration fixes]
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
SPI controller drivers return number of bytes actually transfered from
bitbang->txrx_bufs() method. This updates handling of short transfers (where
the transfer size is less than requested):
- Even zero byte short transfers should report errors;
- Include short transfers in the total of transferred bytes;
- Use EREMOTEIO (like USB) not EMSGSIZE to report short transfers
Short transfers don't normally mean invalid message sizes, but if the
underlying controller driver needs to use EMSGSIZE it can still do so.
[db: fix two more minor issues]
Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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 <nforrester@whoi.edu>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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 <anemo@mba.ocn.ne.jp>
Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove some more references to dev->power.power_state. That field is overdue
for removal, but we can't do that while it's still referenced in the kernel.
The only reason to update it was to make the /sys/devices/.../power/state
files (now removed) work better.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
PBX 2 SPI devices need the nonstandard "cs change per word" mechanism.
This patch is one of three updating this driver to make the last data bits get
sent before advancing the transfer ... in this case, before the chipselect
gets deactivated.
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for SPI over SCI pins. SCI is a very simple serial controller
block that can be found on older SuperH processors. In theory it is
possible to use the SCI hardware block in syncronous mode, but this version
of the driver simply hooks up the bit banging code on the SCI pins.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The two S3C SPI master drivers got merged without much review, so I just
noticed that they're doing something that the SPI core code is responsible
for, rather than any adapter driver: they try to register SPI devices.
This removes that support from those drivers so they act normally.
Interestingly, none of the current boards are affected. So it's a net code
shrink with no loss of functionality.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In atmel_spi_next_xfer, xfer can be NULL because the next transfer may
already have been submitted to the PDC (using DMA chaining). This can
cause an oops, since the debug message assumed it was never null. The
fix changes how those debug messages are issued, ensuring that one is
issued each time a transfer is started instead of once per call.
Also, properly indent the "can this transfer be chained" test so it's
not hidden as if it were non-conditional code.
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for chained transfers in the atmel_spi driver, letting the DMA
controller switch to the next buffer pair without CPU intervention. This
reduced I/O latencies by about 2% in one bulk I/O test. It should also help
work around several interrelated errata affecting chipselect 0 on at91rm9200
chips.
Almost all of the changes are in the reworked atmel_spi_next_xfer() function.
That's now called with the driver in one of three states:
1. It isn't transferring anything (in which case the first transfer
of the current message is going to be sent)
2. It has finished transfering a non-chainable transfer (in which
case it will go to the next transfer in the message)
3. It has finished transfering a chained transfer (in which case the
next transfer is already queued)
After that it will queue the next transfer if it can be chained.
Signed-off-by: Szilveszter Ordog <slipszi@gmail.com>
Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Don't insert (undesirable) delays between consecutive words (DLYBCT) or when
activating chipselects (DLYBS).
Removing the between-word delays improves the performance of bulk transfers
(such as mtd_dataflash, m25p80, mmc_spi) significantly. In one test, the
improvement was a factor of more than eight!
(The large DLYBCT value came from the legacy at91 SPI driver, and it's not
clear why it used such a huge value.)
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
