The commit df59fa7f4b "spi: orion: support armada extended baud
rates" was too optimistic for the maximum baud rate that the Armada
SoCs can support. According to the hardware datasheet the maximum
frequency supported by the Armada 370 SoC is tclk/4. But for the
Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and
for the Armada 375 it is tclk/15.
Currently the armada-370-spi compatible is only used by the Armada 370
and the Armada XP device tree. On Armada 370, tclk cannot be higher
than 200MHz. In order to be able to handle both SoCs, we can take the
minimum of 50MHz and tclk/4.
A proper solution is adding a compatible string for each SoC, but it
can't be done as a fix for compatibility reason (we can't modify
device tree that have been already released) and it will be part of a
separate patch.
Fixes: df59fa7f4b (spi: orion: support armada extended baud rates)
Reported-by: Kostya Porotchkin <kostap@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
If a valid GPIO is specified but cannot be requested by the driver, print a
message and error out of omap2_mcspi_setup.
Signed-off-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The OMAP2_MCSPI_CHCONF_FORCE must be toggled even when using GPIO
chip selects. This patch conditionally calls the omap2_mcspi_set_cs
function to do so when using GPIO chip selects.
Signed-off-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The core spi driver swaps the polarity of the enable based on SPI_CS_HIGH.
The omap2 controller has an internal configuration register bit called
OMAP2_MCSPI_CHCONF_EPOL to handle active high chip selects as well.
So we have to revert swap the polarity back for the correct setting of the
OMAP2_MCSPI_CHCONF_FORCE bit in omap2_mcspi_set_cs.
Signed-off-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The core spi driver handles the delay between transactions.
This is a remanant from the transfer_one conversion.
Signed-off-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Incorrect condition is used in spin_event_timeout(). When the TX is
done, the SPIE_NF bit in ESPI_SPIE register is set to 1 to indicate the
Tx FIFO is not full. If the bit is 0, it indicates the Tx FIFO is full.
Due to this error, if the Tx FIFO is full at the beginning, but becomes
not full after handling the Rx FIFO (the SPIE_NF bit is set), the
spin_event_timeout() returns with timeout occurred. It causes the
interrupt handler not to send completion notification to the thread that
called wait_for_complete() waiting for the notification.
Signed-off-by: Jane Wan <Jane.Wan@gainspeed.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI chip select signal need to keep asserted between several
spi_transfer in the same spi_message usually.
But the driver will de-assert CS signal and the assert it between
serval spi_transfer in the same spi_message under some condiations.
This patch fix the bug.
Here is an example:
Assume you have two variables like the following,
struct spi_transfer a;
struct spi_transfer b;
if you send a spi_message only includes 'a' first,
and then you send a spi_message includes 'a' and 'b'
but without resetting 'a'.
Driver will de-assert CS and then assert CS between 'a' and 'b'.
Signed-off-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
USP is a general purpose serial port in SiRFSoC, which can work as SPI.
the most data flow of USP and pure SPI is same with main differences
in registers layout.
this patch moves registers layout to private data, and use flags to
differentiate other minor differences between prima2-spi, prima2-usp
and atlas7-usp for hardware configuration.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
GPIO chip select patch series appears to have broken the native chip select
support. This patch pulls the manual native chip select toggling out of
the transfer_one routine and adds a set_cs routine.
Tested natively on AM3354 with SPI serial flash on spi0cs0.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Michael Welling <mwelling@ieee.org>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
fixes several warnings/error emmitted by the kbuild system:
* warn: cast from pointer to integer of different size
using size_t instead of u32
* error: 'SZ_4K' undeclared
moved to PAGE_SIZE and PAGE_MASK instead
Review showed also a typo in the same code where tx_buff
was checked twice instead of checking both rx and tx_buff.
Reported by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Conditions per spi_transfer are:
* transfer.len >= 96 bytes (to avoid mapping overhead costs)
* transfer.len < 65536 bytes (limitaion by spi-hw block - could get extended)
* an individual scatter/gather transfer length must be a multiple of 4
for anything but the last transfer - spi-hw block limit.
(some shortcut has been taken in can_dma to avoid unnecessary mapping of
pages which, for which there is a chance that there is a split with a
transfer length not a multiple of 4)
If it becomes a necessity these restrictions can get removed by additional
code.
Note that this patch requires a patch to dma-bcm2835.c by Noralf to
enable scatter-gather mode inside the dmaengine, which has not been
merged yet.
That is why no patch to arch/arm/boot/dts/bcm2835.dtsi is included - the
code works as before without dma when tx/rx are not set, but it writes
a message warning about dma not used:
spi-bcm2835 20204000.spi: no tx-dma configuration found - not using dma mode
To enable dma-mode add the following lines to the device-tree:
dmas = <&dma 6>, <&dma 7>;
dma-names = "tx", "rx";
Tested-by: Noralf Trønnes <noralf@tronnes.org> (private communication)
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix a race (with some kernel configurations) where a queued
master->pump_messages runs and frees dummy_tx/rx before
spi_unmap_msg is running (or is finished).
This results in the following messages:
BUG: Bad page state in process
page:db7ba030 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x200(arch_1)
page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
...
Reported-by: Noralf Trønnes <noralf@tronnes.org>
Suggested-by: Noralf Trønnes <noralf@tronnes.org>
Tested-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
A few driver fixes plus two changes for the core, one to make the
setup_transfer() callback optional which fixes crashes in some drivers
which were updated to use new interfaces without apparent testing and
one to ensure we don't expose the data buffers we use for dummy
transfers to drivers which avoids potential issues with multiple
accesses to them or reuse.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVO2WTAAoJECTWi3JdVIfQ19wH/2c3NnRGoj5Oz6ltE2Yv2fXd
MZJa/pmb7rUsxB7lwffnmOZj2XZucYg05hChdYnAIV5NtwZlf2xd+s7/kWbhTOdJ
YeFdENjODrfnfBI4Ka82T2wIjFi1KEIDYMY5SyotGRdgl7NyK2atjna/2j/iAggm
PJljJOzzibHGx8tvQcLGNDOeoHXLzUTBg4bOcESTs63447+bn4UQgKVolEC6FY4f
d61T7NVbdWUpwInsj5lFmjkl/w02N5WHNrpChE+AbBk++rBbE2TrJxuRUF2DstVF
LLT5LKGygZVuTjshnlJwMYKT3m3s9qeSGUJJ5u2NIfLe0L2dp/1pZV84OOPFiN4=
=c+gA
-----END PGP SIGNATURE-----
Merge tag 'spi-v4.1-rc1' into spi-linus
spi: Fixes for v4.1
A few driver fixes plus two changes for the core, one to make the
setup_transfer() callback optional which fixes crashes in some drivers
which were updated to use new interfaces without apparent testing and
one to ensure we don't expose the data buffers we use for dummy
transfers to drivers which avoids potential issues with multiple
accesses to them or reuse.
# gpg: Signature made Sat 25 Apr 2015 10:59:47 BST using RSA key ID 5D5487D0
# gpg: key CD7BEEBC: no public key for trusted key - skipped
# gpg: key CD7BEEBC marked as ultimately trusted
# gpg: key AF88CD16: no public key for trusted key - skipped
# gpg: key AF88CD16 marked as ultimately trusted
# gpg: key 16005C11: no public key for trusted key - skipped
# gpg: key 16005C11 marked as ultimately trusted
# gpg: key 5621E907: no public key for trusted key - skipped
# gpg: key 5621E907 marked as ultimately trusted
# gpg: key 5C6153AD: no public key for trusted key - skipped
# gpg: key 5C6153AD marked as ultimately trusted
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
Remove unneeded variable used to store return value.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/returnvar.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If GPIO chip select is specified, request the GPIO in the setup function
and release it in the cleanup function.
Signed-off-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Switches from transfer_one_message to transfer_one to prepare driver for
use of GPIO chip selects.
Signed-off-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
To reduce indentation and complexity of code, insteeds of returning zero
the function rspi_dma_check_then_transfer should return rspi_dma_transfer
directly after checking error.
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Signed-off-by: Mark Brown <broonie@kernel.org>
move spi controller's gpio request work out from probe() to spi device
register stage, so after spi device register spi controller can deactive
device's gpio chipselect. old code can't do it because gpio request has
not be done until device register is finised in spi_bitbang_start.
and add cleanup function to free CS gpio.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.
Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
I got following error on CONFIG_GPIOLIB=n.
drivers/spi/spi-bcm2835.c: In function 'chip_match_name':
drivers/spi/spi-bcm2835.c:356:21: error: dereferencing pointer to incomplete type 'struct gpio_chip'
return !strcmp(chip->label, data);
^
drivers/spi/spi-bcm2835.c: In function 'bcm2835_spi_setup':
drivers/spi/spi-bcm2835.c:382:9: error: implicit declaration of function 'gpiochip_find' [-Werror=implicit-function-declaration]
chip = gpiochip_find("pinctrl-bcm2835", chip_match_name);
^
drivers/spi/spi-bcm2835.c:382:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
chip = gpiochip_find("pinctrl-bcm2835", chip_match_name);
^
drivers/spi/spi-bcm2835.c: In function 'chip_match_name':
drivers/spi/spi-bcm2835.c:357:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
return error for unsupported bits-per-word format, BUG() is not right
for this scenerios as we are not an ASSERT but an error handler.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <baohua.song@csr.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The polling mode of the driver is designed for transfers that run
less than 30us - it will only execute under those circumstances.
So it should run comfortably without getting interrupted by the
scheduler.
But there are situations where the raspberry pi is so overloaded
that it can take up to 80 jiffies until the polling thread gets
rescheduled - this has been observed especially under heavy
IO situations.
In such a situation we now fall back to the interrupt handler and
log the situation at debug level.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The way that the timeout code is written in the polling function
the timeout does also trigger when interrupted or rescheduled while
in the polling loop.
This patch changes the timeout from effectively 20ms (=2 jiffies) to
1 second and removes the time that the transfer really takes out of
the computation, as - per design - this is <30us and the jiffie resolution
is 10ms so that does not make any difference what so ever.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The internal chip select CS0 wasn't initialized properly to work with
CS HIGH chips.
Signed-off-by: Alban Bedel <albeu@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Clocks should be prepared and unprepared, fix this by using
clk_prepare_enable() and clk_disable_unprepare() instead of
clk_enable() and clk_disable().
Signed-off-by: Alban Bedel <albeu@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the OF node of the spi controller and use the generic GPIO based
chip select instead of the custom controller data. As the controller
data isn't used by any board just drop it.
Signed-off-by: Alban Bedel <albeu@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch makes possible for protocol drivers to do full-duplex SPI
transfers properly. Until now this driver could only be used for
half-duplex transfers, since it always expected an spi_transfer with
non-null tx_buf to be only used for TX, and those with non-null rx_buf
to be only used for RX.
The fix consists in correcting the fsl_espi_transfer length by taking
into consideration duplex spi_transfers, and not just by adding n_tx
and n_rx.
Furthermore, this correction has exposed an inconsistency in the
protocol driver <-> controller driver interaction. The spi-fsl-espi
driver artificially inserts TX bytes when message fragmentation is
necessary (due to SPCOM_TRANLEN_MAX) instead of informing the
protocol driver of the hardware limitation. This was tested with the
m25p80 NOR flash protocol driver. Since fixing this issue may cause
other client drivers to malfunction, it was left as is.
Signed-off-by: Jonatas Rech <jonatas.rech@datacom.ind.br>
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_ioremap_resource() doesn't return NULL but an ERR_PTR on error.
Reported-by: Jonas Gorsky <jogo@openwrt.org>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
LS1021A chip also has the DSPI module.
Add it to the dependence.
Signed-off-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It is unnecessary for DSPI to enable/disable clk when access DSPI register.
And it will reduce efficiency.
Signed-off-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The spi queue waits forever for spi_finalize_current_message() to be
called, blocking the bus. Ensure that all error paths from
omap2_mcspi_transfer_one_message() call spi_finalize_current_message().
Signed-off-by: Fionn Cleary <fionn.cleary@streamunlimited.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This has the benefit that the "optimization" of the framework in regards
to spi_sync will also benefit spidev users directly and allow running
spi transfers without a necessary context-switch to message-pump.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
On CPM2, the SPI parameter RAM is dynamically allocated in the
dualport RAM whereas in CPM1, it is statically allocated to a default
address with capability to relocate it somewhere else via the use of
CPM micropatch. The address of the parameter RAM is given by the boot
loader and expected to be mapped via devm_ioremap_resource()
In the current implementation, in function fsl_spi_cpm_get_pram()
there is a confusion between the SPI_BASE register and the base of the
SPI parameter RAM. Fortunatly, it is working properly with MPC866 and
MPC885 because they do set SPI_BASE, but on MPC860 and other old
MPC8xx that doesn't set SPI_BASE, pram_ofs is not properly set.
Also, the parameter RAM is not properly mapped with
devm_ioremap_resource() as it should but still gets accessible by
chance through the full RAM which is mapped from somewhere else.
This patch applies to the SPI driver the same principle as for the
CPM UART: when the CPM is of type CPM1, we simply do an
devm_ioremap_resource() of the area provided via the device tree.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
As it turns out, the set_cs() enable parameter refers to the logic level
on the CS pin, not the state of chip selection.
This broke functionality of the LEDs behind the CPLD, or at least delayed
the commands until another one came in to toggle CS.
Signed-off-by: Bert Vermeulen <bert@biot.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver mediates access between the connected CPLD and other devices
on the bus.
The m25p80-compatible boot flash and (some models) MMC use regular SPI,
bitbanged as required by the SoC. However the SPI-connected CPLD has
a two-wire mode, in which two bits are transferred per SPI clock
cycle. The second bit is transmitted with the SoC's CS2 pin.
Signed-off-by: Bert Vermeulen <bert@biot.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some controller drivers have no need of this callback (spi-altera even
causes a NULL pointer dereference because it doesn't register the callback,
falsely assuming that it is already optional).
Fixes: 30af9b558a ("spi/bitbang: Drop empty setup() functions")
Signed-off-by: Pelle Nilsson <per.nilsson@xelmo.com>
Reviewed-by: Ezequiel Garcia <ezequiel.garcia@vanguardiasur.com.ar>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some spi device drivers use the same tx_buf and rx_buf repeatly for better
performance such as driver/input/touchsreen/ads7846.c, but spi core grab tx_buf
/rx_buf of transfer and set them as dummy_tx/dummy_rx once they are NULL. Thus,
in the second time the tx_buf/rx_buf will be replaced by dummy_tx/dummy_rx and
the data which produced by the last tx or rx may be wrongly sent to the device
or handled by the upper level protocol. This patch just keep the orignal value
of tx_buf/rx_buf if they are NULL after this transfer processed.
Signed-off-by: Robin Gong <b38343@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The way that the timeout code is written in the polling function
the timeout does also trigger when interrupted or rescheduled while
in the polling loop.
This patch changes the timeout from effectively 20ms (=2 jiffies) to
1 second and removes the time that the transfer really takes out of
the computation, as - per design - this is <30us and the jiffie resolution
is 10ms so that does not make any difference what so ever.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix:
drivers/spi/spi-bcm2835.c: In function 'chip_match_name':
drivers/spi/spi-bcm2835.c:356:21: error:
dereferencing pointer to incomplete type
drivers/spi/spi-bcm2835.c: In function 'bcm2835_spi_setup':
drivers/spi/spi-bcm2835.c:382:2: error:
` implicit declaration of function 'gpiochip_find'
drivers/spi/spi-bcm2835.c:387:21: error:
dereferencing pointer to incomplete type
by adding the now mandatory GPIOLIB dependency.
Fixes: a30a555d74 ("spi: bcm2835: transform native-cs to gpio-cs
on first spi_setup")
Cc: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
In cases of short transfer times the CPU is spending lots of time
in the interrupt handler and scheduler to reschedule the worker thread.
Measurements show that we have times where it takes 29.32us to between
the last clock change and the time that the worker-thread is running again
returning from wait_for_completion_timeout().
During this time the interrupt-handler is running calling complete()
and then also the scheduler is rescheduling the worker thread.
This time can vary depending on how much of the code is still in
CPU-caches, when there is a burst of spi transfers the subsequent delays
are in the order of 25us, so the value of 30us seems reasonable.
With polling the whole transfer of 4 bytes at 10MHz finishes after 6.16us
(CS down to up) with the real transfer (clock running) taking 3.56us.
So the efficiency has much improved and is also freeing CPU cycles,
reducing interrupts and context switches.
Because of the above 30us seems to be a reasonable limit for polling.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Transforms the bcm-2835 native SPI-chip select to their gpio-cs equivalent.
This allows for some support of some optimizations that are not
possible due to HW-gliches on the CS line - especially filling
the FIFO before enabling SPI interrupts (by writing to CS register)
while the transfer is already in progress (See commit: e3a2be3030)
This patch also works arround some issues in bcm2835-pinctrl which does not
set the value when setting the GPIO as output - it just sets up output and
(typically) leaves the GPIO as low. When a fix for this is merged then this
gpio_set_value can get removed from bcm2835_spi_setup.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When the CONTINUE bit is set, the interrupt status we are polling to
identify if a transaction has finished can be sporadic. Even though
the transfer has finished, the interrupt status may erroneously
indicate that there is still data in the FIFO. This behaviour causes
random timeouts in large PIO transfers.
Instead of using the CONTINUE bit to control the CS lines, use the SPI
core's CS GPIO handling. Also, now that the CONTINUE bit is not being
used, we can poll for the ALLDONE interrupt to indicate transfer
completion.
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Imagination has recommended that the SPFI controller be reset after
each message, regardless of success or failure. Do this in an
unprepare_message() callback.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver can be greatly simplified by moving the transfer timeout
handling to a handle_err() callback.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Setting the transfer length in the TRANSACTION register after the
CONTROL register is programmed causes intermittent timeout issues in
SPFI transfers when using the SPI framework to control the CS GPIO
lines. To avoid this issue, set transfer length before programming
the CONTROL register.
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
If a driver doesn't implement the master->handle_err() callback and an
SPI transfer fails, the kernel will crash with a NULL pointer
dereference:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0003000
[00000000] *pgd=80000040004003, *pmd=00000000
Internal error: Oops: 80000206 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc7-koelsch-05861-g1fc9fdd4add4f783 #1046
Hardware name: Generic R8A7791 (Flattened Device Tree)
task: eec359c0 ti: eec54000 task.ti: eec54000
PC is at 0x0
LR is at spi_transfer_one_message+0x1cc/0x1f0
Make the master->handle_err() callback optional to avoid the crash.
Also fix a spelling mistake in the callback documentation while we're at
it.
Fixes: b716c4ffc6 ("spi: introduce master->handle_err() callback")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Although the SPFI BITCLK divider supports a value of up to 255, only
values up to 128 are usable. This results in a maximum possible bit
clock rate of 1/4th the input clock rate.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
In preparation for switching to using the SPI core's CS GPIO handling,
move setup of the PORT_STATE register, which must be configured before
CS is asserted, to a prepare_message() callback.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add delay between chip select and clock signals, before clock starts and
after clock stops.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).
Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR. The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).
Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We need "ret" to be unsigned for the error handling to work. The
signedness of "i" and "n" don't matter but qspi_set_send_trigger()
returns an int so I've changed them to int as well.
Fixes: 4b6fe3edcb ('spi: Using Trigger number to transmit/receive data')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
They are used to decide if the controller can do DMA on a buffer
of a specific length and thus are needed before any transfer is attempted.
This fixes a memory leak where the SPI core uses the drivers can_dma()
callback to determine if a buffer needs to be mapped. As the watermark
levels aren't correct at that point the driver falsely claims to be able to
DMA the buffer when it fact it isn't.
After the transfer has been done the core uses the same callback to
determine if it needs to unmap the buffers. As the driver now correctly
claims to not being able to DMA the buffer the core doesn't attempt to
unmap the buffer which leaves the SGT leaking.
Fixes: f62caccd12 (spi: spi-imx: add DMA support)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
cr_width may be not initialized before using by cr, the related warning
(with defconfig under blackfin by gcc5):
CC drivers/spi/spi-bfin5xx.o
drivers/spi/spi-bfin5xx.c: In function 'bfin_spi_pump_transfers':
drivers/spi/spi-bfin5xx.c:655:5: warning: 'cr_width' may be used uninitialized in this function [-Wmaybe-uninitialized]
cr |= cr_width;
^
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The current implementation of bitbang_txrx_be_cpha0 and
bitbang_txrx_be_cpha1 always call setmosi. That runs into several
unnecessary calls into the gpiolib when the level of the GPIO actually
has not to be changed.
This patch changes the routines to remember the last GPIO level
and only calls setmosi if an change has to be made. This
way it improves the transfer throughput.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
We refactored this code but accidentally left out a break statement so
QUARK_X1000_SSP isn't handled correctly.
Fixes: 025ffe88ee ('spi: pxa2xx: shift clk_div in one place')
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).
Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR. The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).
Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to transmit and receive data when have 32 bytes of data that
ready has prepared on Transmit/Receive Buffer to transmit or receive.
Instead transmits/receives a byte data using Transmit/Receive Buffer
Data Triggering Number will improve the speed of transfer data.
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Signed-off-by: Mark Brown <broonie@kernel.org>
To reduce the number of interrupts/message we fill the FIFO before
enabling interrupts - for short messages this reduces the interrupt count
from 2 to 1 interrupt.
There have been rare cases where short (<200ns) chip-select switches with
native CS have been observed during such operation, this is why this
optimization is only enabled for GPIO-CS.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Tested-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since spidev is a detail of how Linux controls a device rather than a
description of the hardware in the system we should never have a node
described as "spidev" in DT, any SPI device could be a spidev so this
is just not a useful description.
In order to help prevent users from writing such device trees generate a
warning if spidev is instantiated as a DT node without an ID in the match
table.
Signed-off-by: Mark Brown <broonie@kernel.org>
This also allows for GPIO-CS to get used removing the limitation of
2/3 SPI devises on the SPI bus.
Fixes: spi-cs-high with native CS with multiple devices on the spi-bus
resetting the chip selects to "normal" polarity after a finished
transfer.
No other functionality/improvements added.
Tested with the following 4 devices on the spi-bus:
* mcp2515 with native CS
* mcp2515 with gpio CS
* fb_st7735r with native CS
(plus spi-cs-high via transistor inverting polarity)
* enc28j60 with gpio-CS
Tested-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
We have found that we can sometimes see read failures on boards with
high-capacitance SPI lines. It seems that the controller samples the Rx
data line too early, and its register interface has an "Rx Sample Delay"
setting to fine-tune against this issue.
This patch adds a new optional device tree entry that can configure this
delay in terms of nanoseconds. The kernel will calculate the
best-fitting amount of parent clock ticks to program the controller with
based on that.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Rockchip SPI driver currently calculates its clock rate divisor by
integer dividing the parent rate by the target rate, and then rounding
the result up to the next even number (since the divisor must be
even).
Clock rate divisors should always be rounded up, so that the resulting
frequency is lower or equal to the target. This is correctly done in the
second step here but not in the first, so we still have a risk of
exceeding the desired target frequency (e.g. setting spi-max-frequency
to 40000000 with a parent clock of 99000000 could lead to a divisor of
99000000 / 40000000 == 2 (which is even) that then results in an
effective frequency of 99000000 / 2 == 49500000 (potentially exceeding
the flash chip's specifications).
This patch changes the division to round up to fix this problem.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Trying to register an SPI device asynchronously (via async_schedule() call)
results in an ugly complaint from request_module() warning about potential
deadlock (because request_module tries to wait for async works to
complete, the caller is also an async work in this case).
While we could try to switch to using request_module_nowait(), other buses,
as well as SPI itself when not using device tree, do not try to load
modules explicitly, but rather rely on the standard infrastructure (such as
udev) to execute module loading. There is no reason why SPI OF-described
devices should be treated differently.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The commit 1a7b7ee72c (spi: Ensure that CS line is in non-active state after
spi_setup()) introduces an unconditional call of spi_set_cs() before ->setup().
The dw_spi_set_cs() relies on that fact that ->setup() is already called, but
it doesn't now. This patch fixes the crash by adding an additional check to
dw_spi_set_cs().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Quark SoC data sheet describes the baud rate setting using fractional
divider. The subset of possible values represented by a table suggests that the
divisor has one block that could divide by 5. This explains the number of the
beast in some cases in the table. Thus, in this particular case the divisor can
be evaluated as
5^i * 2^j * 2 * k,
where
i = [0, 1]
j = [0, 23]
k = [1, 256]
There are few cases as mentioned in the data sheet, i.e. better form of the
clock signal will be in case if DDS_CLK_RATE either 2^n or 2/5. It's also
possible to use any value that is less or equal to 0x33333 (1/5/16 = 1/80).
All three cases are compared to each other and the one that suits better is
chosen by the approximation algorithm. Anyone can play with the script [1] that
represents the algorithm.
[1] https://gist.github.com/06b084488b3629898121
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch refactors ssp_get_clk_div() and pxa2xx_ssp_get_clk_div() to align
clk_div calculations, i.e. ssp_get_clk_div() and quark_x1000_set_clk_regvals()
will return plain clk_div and it will be shifted to proper position in
pxa2xx_ssp_get_clk_div().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
`spidev_message()` sums the lengths of the individual SPI transfers to
determine the overall SPI message length. It restricts the total
length, returning an error if too long, but it does not check for
arithmetic overflow. For example, if the SPI message consisted of two
transfers and the first has a length of 10 and the second has a length
of (__u32)(-1), the total length would be seen as 9, even though the
second transfer is actually very long. If the second transfer specifies
a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could
overrun the spidev's pre-allocated tx buffer before it reaches an
invalid user memory address. Fix it by checking that neither the total
nor the individual transfer lengths exceed the maximum allowed value.
Thanks to Dan Carpenter for reporting the potential integer overflow.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
The official documentation is wrong in this respect.
Has been tested empirically for dividers 2-1024
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement the recommendation from the BCM2835 data-sheet
with regards to polling drivers to fill/drain the FIFO as much data as possible
also for the interrupt-driven case (which this driver is making use of).
This means that for long transfers (>64bytes) we need one interrupt
every 64 bytes instead of every 12 bytes, as the FIFO is 16 words (not bytes) wide.
Tested with mcp251x (can bus), fb_st7735 (TFT framebuffer device)
and enc28j60 (ethernet) drivers.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
asm/irq.h is already included by linux/interrupt.h.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These asm/io.h, asm/irq.h and asm/delay.h are needless since they are
already included by linux/io.h via drivers/spi/spi-pxa2xx.h,
linux/interrupt.h and linux/delay.h.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the endian agnositc IO functions instead of the __raw ones for when
the driver is in use on big-endian systems.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
