When either rx_buf or tx_buf is not being used, i.e.  for plain read- or
write operations, the atmel_spi uses a fixed-size DMA buffer instead.  If
the transfer is longer than the size of this buffer, it is split into
multiple DMA transfers.

When the transfer is split like this, the atmel_spi driver ends up using
the same DMA address again and again even for the buffer that came from the
user, which is of course wrong.  Fix this by adding the number of bytes
already transferred to the DMA address so that the data ends up in the
right place.

Thanks to Wu Xuan for discovering this bug.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Now that the cpu_is_xxx() macros are available both on AVR32 and AT91, we can
remove a couple of #ifdefs from this driver.  One of them is actually wrong --
new_1 should be set on AVR32 but isn't.  This causes the bus clock to run at
twice the speed it is configured to.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Cc: David Brownell <david-b@pacbell.net>
Acked-by: NAndrew Victor <andrew@sanpeople.com>
Cc: Nicolas Ferre <nicolas.ferre@rfo.atmel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It's been pointed out that output GPIOs should have an initial value, to
avoid signal glitching ...  among other things, it can be some time before
a driver is ready.  This patch corrects that oversight, fixing

 - documentation
 - platforms supporting the GPIO interface
 - users of that call (just one for now, others are pending)

There's only one user of this call for now since most platforms are still
using non-generic GPIO setup code, which in most cases already couples the
initial value with its "set output mode" request.

Note that most platforms are clear about the hardware letting the output
value be set before the pin direction is changed, but the s3c241x docs are
vague on that topic ...  so those chips might not avoid the glitches.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NAndrew Victor <andrew@sanpeople.com>
Acked-by: NMilan Svoboda <msvoboda@ra.rockwell.com>
Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The signature of the per-device cleanup() routine changed to remove its
const-ness.  Three new SPI controller drivers now need that change, to
eliminate build warnings.

This also fixes a build bug with atmel_spi on AT91 systems.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Driver for the Atmel on-chip SPI master controller.

Tested primarily on AVR32/AT32AP7000/ATSTK1000 using mtd_dataflash and the
jffs2 filesystem.  Should also work fine on various AT91 ARM-based chips
like AT91SAM926x and AT91RM9200.

Hardware documentation can be found in the AT32AP7000 data sheet, or its
AT91 siblings, which can be downloaded from

http://www.atmel.com/dyn/products/datasheets.asp?family_id=682Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>