aboutsummaryrefslogtreecommitdiff
path: root/drivers/spi/atmel_spi.c
AgeCommit message (Collapse)Author
2008-02-23atmel_spi: fix clock polarityAtsushi Nemoto
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>
2008-02-06atmel_spi: fix dmachain oops with DEBUG enabledHaavard Skinnemoen
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>
2008-02-06atmel_spi: chain DMA transfersSilvester Erdeg
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>
2008-02-06atmel_spi throughput improvementHaavard Skinnemoen
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>
2007-12-10atmel_spi: reload RCR before TCRRini van Zetten
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 <hskinnemoen@atmel.com> Signed-off-by: Rini van Zetten <rini@arvoo.nl> 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>
2007-11-29atmel_spi: label GPIOs betterDavid Brownell
Make the atmel_spi driver label GPIOs according to the device for which they're acting as a chipselect. This way the debugfs dump of gpio state is more informative. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-16spi doesn't need class_deviceTony Jones
Make the SPI framework and drivers stop using class_device. Update docs accordingly ... highlighting just which sysfs paths should be "safe"/stable. Signed-off-by: Tony Jones <tonyj@suse.de> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-08-31Fix typo in atmel_spi.cAndrew Victor
Fix cut 'n paste bug in Atmel SPI driver. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Acked-by: David Brownell <david-b@pacbell.net> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-17atmel_spi: don't always deselect chip between messagesDavid Brownell
Update chipselect handling for atmel_spi: * Teach it how to leave chipselect active between messages; this helps various drivers work better. * Cope with at91rm0200 errata: nCS0 can't be managed with GPIOs. The MR.PCS value is now updated whenever a chipselect changes. (This requires SPI pinmux init for that controller to change, and also testing on rm9200; doesn't break at91sam9 or avr32.) * Fix minor glitches: spi_setup() must leave chipselects inactive, as must removal of the spi_device. Also tweak diagnostic messaging to be a bit more useful. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-17atmel_spi: minor updatesDavid Brownell
Minor updates to atmel_spi: - DMA: * Comments to explain the DMA policies * Report any mapping errors from spi_transfer() * Remove extra loop for DMA mapping - Diagnostics: report minimum clock rate, if we need to reject a spi_setup() request because that rate is too low. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-17SPI controller drivers: check for unsupported modesDavid Brownell
Minor SPI controller driver updates: make the setup() methods reject spi->mode bits they don't support, by masking aginst the inverse of bits they *do* support. This insures against misbehavior later when new mode bits get added. Most controllers can't support SPI_LSB_FIRST; more handle SPI_CS_HIGH. Support for all four SPI clock/transfer modes is routine. 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>
2007-06-01atmel_spi dma address bugfixHaavard Skinnemoen
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: 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>
2007-05-09atmel_spi: remove unnecessary (and wrong) #ifdefsHaavard Skinnemoen
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: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: David Brownell <david-b@pacbell.net> Acked-by: Andrew Victor <andrew@sanpeople.com> Cc: Nicolas Ferre <nicolas.ferre@rfo.atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-16[PATCH] gpio_direction_output() needs an initial valueDavid Brownell
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: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Andrew Victor <andrew@sanpeople.com> Acked-by: Milan Svoboda <msvoboda@ra.rockwell.com> Acked-by: Haavard Skinnemoen <hskinnemoen@atmel.com> 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>
2007-02-20[PATCH] SPI controller build/warning fixesDavid Brownell
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: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-14[PATCH] SPI: atmel_spi driverHaavard Skinnemoen
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=682 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>