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 <kalle.valo@nokia.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>
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>
- 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 <bryan.wu@analog.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 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 <bryan.wu@analog.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>
Fix SPI driver to work with SPI flash ST M25P16 on bf548
Currently the SPI driver enables the SPI controller and sets the SPI baud
register for each SPI transfer. But they should never be changed within a SPI
message session, in which several SPI transfers are pumped.
This patch moves SPI setting to the begining of a message session, and
never disables SPI controller until an error occurs.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
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>
Simplify spi_sync calling convention, eliminating the need to check both
the return value AND the message->status. In consequence, this corrects
misbehaviours of spi_read and spi_write (which only checked the former) and
their callers.
Signed-off-by: Marc Pignat <marc.pignat@hevs.ch>
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 comment to at25 driver that it's for EEPROM chips, not FLASH
chips ... the AT25 series has both types of chip, and sometimes
they're even pin-compatible. The command sets are different, as
is the treatment of erasure. (FLASH needs explicit erasure, but
with EEPROM it's implicit.) Note that all vendors seem to have
this same confusion in their *25* series SPI memory parts.
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>
If we specify an GPIO which cannot be used for the purpose, then assume
that the GPIO is not to be used and do not try and configure it. This can
be the case where the SPI bus is TX only.
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>
Use of ptrdiff_t in places like
- if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
+ if (!access_ok(VERIFY_WRITE, (u8 __user *)
+ (ptrdiff_t) u_tmp->rx_buf,
+ u_tmp->len))
is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general
we are not even promised that ptrdiff_t is large enough to hold a pointer,
just enough to hold a difference between two pointers within the same object).
For another, it confuses the fsck out of sparse.
Use unsigned long or uintptr_t instead. There are several places misusing
ptrdiff_t; fixed.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix the various misspellings of "system", controller", "interrupt" and
"[un]necessary".
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Shrink the runtime footprint of various SPI drivers:
- Move the probe() routine into the init section where practical,
using platform_driver_probe() to make that safe. This often saves
around 1KB. Using platform_driver_probe() can also be a correctness
fix, if the probe routine is already marked __init but the driver
struct keeps a dangling pointer to it after init section removal.
- Likewise move remove() routines into the exit sections.
These changes would be inappropriate iff the platform devices were
actually hotpluggable (e.g. they're found on optional addon cards,
or in an FPGA that's dynamically reprogrammed). In these cases,
that's not the situation; it's an SOC controller and the only device
is initialized before these drivers.
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>
This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.
Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the spi_mpc83xx driver receives a tx_buf pointer which is NULL, it
only writes one zero filled word to the transmit register. If the driver
expects to receive more than one word it will wait forever for a second
receive interrupt. With this patch the controller will shift out zeroes
until all words have been received.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update various SPI drivers so they properly support
- coldplug through "modprobe $(cat /sys/devices/.../modalias)"
- hotplug through "modprobe $(MODALIAS)"
The basic rule for platform, SPI, and (new style) I2C drivers is just
to make sure that modprobing the driver name works. In this case, all
the relevant drivers are platform drivers, and this patch either
(a) Changes the driver name, if no in-tree code would break;
this is simpler and thus preferable in the long term.
(b) Adds MODULE_ALIAS directives, when in-tree platforms declare
devices using the current driver name; less desirable.
Most systems will link SPI controller drivers statically, but
there's no point in being needlessly broken.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Jean Delvare <khali@linux-fr.org>
Acked-by: Andrei Konovalov <akonovalov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git rid of "warning: passing arg 2 of `access_ok' makes pointer from integer
without a cast" reported on SH ... most architectures use macros in that
test, SH uses inlined functions.
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>
Long ago I've noticed (but didn't pay much attention) that
spi_mpc83xx using PM calculations that differs from what
specs describe. I.e.
u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
While specs says: "The SPI baud rate generator clock source (either
system clock or system clock divided by 16, depending on DIV16 bit) is
divided by 4 * ([PM] + 1), a range from 4 to 64.".
Thus " - 1" is missing in the spi_mpc83xx's formula.
Why nobody noticed that bug? Probably because sysclk usually less then
user expects, e.g. you expect 200 MHz, but real clock is 198 MHz,
and integer rounding helps when this formula is used.
Suppose it's SPI in QE, SYSCLK at 198 MHz, thus SPIBRG at 99MHz, 25 MHz
requested.
PM = (99MHz / ( 25 MHz * 4 )), PM == 0, output SPICLK will be 24.75 MHz
At lower frequencies this bug is more noticeable, though.
And this bug shows itself in all its beauty if SYSCLK is equal or a bit
more than you expect (200 MHz SYSCLK, 100 MHz SPIBRG):
PM = (100MHz / ( 25 MHz * 4 )), PM == 1, output SPICLK will be 12.625 MHz!
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.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>
