In commit f814f9ac5a ("spi/orion: add device tree binding"), Device
Tree support was added to the spi-orion driver. However, this commit
reads the "cell-index" property, without taking into account the fact
that DT properties are big-endian encoded.
Since most of the platforms using spi-orion with DT have apparently
not used anything but cell-index = <0>, the problem was not
visible. But as soon as one starts using cell-index = <1>, the problem
becomes clearly visible, as the master->bus_num gets a wrong value
(actually it gets the value 0, which conflicts with the first bus that
has cell-index = <0>).
This commit fixes that by using of_property_read_u32() to read the
property value, which does the appropriate endianness conversion when
needed.
Fixes: f814f9ac5a ("spi/orion: add device tree binding")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org> # v3.6+
The s3c64xx SPI driver uses a custom DT binding to specify
the GPIO used to drive the chip select (CS) line instead of
using the generic "cs-gpios" property already defined in:
Documentation/devicetree/bindings/spi/spi-bus.txt.
It's unfortunate that drivers are not using standard bindings
and creating custom ones instead but in most cases this can't
be changed without breaking Device Tree backward compatibility.
But in the case of this driver, its DT binding has been broken
for more than a year. Since after commit (dated June, 21 2013):
3146bee ("spi: s3c64xx: Added provision for dedicated cs pin")
DT backward compatibility was broken and nobody noticed until
now when the commit was reverted. So it seems to be safe to
change the binding to use the standard SPI "cs-gpios" property
instead of using a custom one just for this driver.
This patch also allows boards that don't use a GPIO pin for the
CS to work with the driver since the SPI core will take care of
setting spi->cs_gpio to -ENOENT if a board wants to use the built
in CS instead of a GPIO as explained in the SPI bus DT binding:
Documentation/devicetree/bindings/spi/spi-bus.txt.
For non-DT platforms, spi->cs_gpio will be set to -ENOENT as well
unless they specify a GPIO pin in their platform data. So both
native and GPIO chip select is also supported for legacy boards.
The above use case was what motivated commit 3146bee which broke
the DT binding backward compatibility in the first place.
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
[javier.martinez@collabora.co.uk: split changes and improve commit message]
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This reverts commit 3146beec21.
This commit resulted in a DT backward compatibility breakage.
Some devices use the native chip select (CS) instead of a GPIO
pin to drive the CS line. But the SPI driver made it mandatory
to specify a GPIO pin in the SPI device node controller-data.
So, using the built-in CS was not possible with the driver.
Commit 3146bee tried to fix that by adding a "cs-gpio" property
which could be defined in the SPI device node to make the driver
request the GPIO from the controller-data node.
Unfortunately that changed the old DT binding semantics since
now it's mandatory to have the "cs-gpio" property defined in
the SPI device node in order to use a GPIO pin to drive the CS.
As an example, a SPI device was defined before the commit with:
spi@12d20000 {
slave-node@0 {
controller-data {
cs-gpio = <&gpb1 2 0>;
}
}
}
and after the commit, the following DTS snippet must be used:
spi@12d20000 {
cs-gpio;
slave-node@0 {
controller-data {
cs-gpio = <&gpb1 2 0>;
}
}
}
So, after commit 3146bee the driver does not look for the GPIO
by default and it only looks for it if the top level "cs-gpio"
property is defined while the default used to be the opposite.
To always request the GPIO defined in the controller-data node.
This means that old FDT that of course didn't have this added
"cs-gpio" DT property in the SPI node broke after this change.
The offending commit can't be reverted cleanly since more than
a year have passed and other changes were made in the meantime
but this patch partially reverts the driver to it's original
state so old FDT can work again.
This patch will break Device Trees that were relying on the new
behavior of course but the patch should be reverted because:
a) There aren't DTS in mainline that use this new property.
b) They were relying on a behavior that broke DT compatibility.
c) The new binding is awkard, needing two properties with the
same name (cs-gpio) on different nodes is confusing at least.
d) The new property was not added to the DT binding doc:
Documentation/devicetree/bindings/spi/spi-samsung.txt
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently the cadence SPI driver does the SPI clock configuration (setup CPOL
and CPHA) in the prepare_transfer_hardware() callback. The
prepare_transfer_hardware() callback is only called though when the controller
transitions from a idle state to a non-idle state. Such a transitions happens
when the message queue goes from empty to non-empty. If multiple messages from
different SPI slaves with different clock settings are in the message queue the
clock settings will not be properly updated when switching from one slave device
to another. Instead do the updating of the clock configuration in the
prepare_message() callback which will be called for each individual message.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
It seems that the cadence SPI controller does not immediately change the clock
polarity setting when writing the CR register. Instead the change is delayed
until the next transfer starts. This happens after the chip select line has
already been asserted. As a result the first transfer after a clock polarity
change will generate spurious clock transitions which typically results in the
SPI slave not being able to properly understand the message. Toggling the ER
register seems to cause the SPI controller to apply the clock polarity changes,
so implement this as a workaround to fix the issue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
According to Documentation/dmaengine.txt, scatterlists must be mapped
using the DMA struct device.
However, "dma_chan.dev->device" is the sysfs class device's device.
Use "dma_chan.device->dev" instead, which is the real DMA device's device.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
According to Documentation/DMA-API.txt, dma_map_sg() returns 0 on failure.
As spi_map_buf() returns an error code, convert zero into -ENOMEM.
Keep the existing check for negative numbers just in case.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The Xilinx SPI driver initializes the bus_num field of the SPI master to
pdev->dev.id. pdev->dev.id is always 0 for platform devices which causes bus
number conflicts for the SPI controller when creating multiple device instances
of the driver. Instead use pdev->id which will have the assignt platform device
id. If the device is instantiated via devicetree pdev->id is -1 which will cause
the SPI core to dynamically assign a id (or use the id defined via a alias in
the devicetree).
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
This patch fixes a bug on the deallocation of memory allocated using
request_mem_region, by using release_mem_region instead of
release_resource and kfree.
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Commit id 2bd16e3e23
(spi: omap2-mcspi: Do not configure the controller
on each transfer unless needed) does its job too
well so omap2_mcspi_setup_transfer() isn't called
even when an SPI slave driver changes 'spi->mode'.
The result is that the mode requested by the SPI
slave driver never takes effect.
Fix this by adding the 'mode' member to the
omap2_mcspi_cs structure which holds the mode
value that the hardware is configured for.
When the SPI slave driver changes 'spi->mode'
it will be different than the value of this new
member and the SPI master driver will know that
the hardware must be reconfigured (by calling
omap2_mcspi_setup_transfer()).
Fixes: 2bd16e3e23 (spi: omap2-mcspi: Do not configure the controller on each transfer unless needed)
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
This patch removes the chip select function. Chip select should instead be
supported using GPIOs, defining the DT entry "cs-gpios", and letting the SPI
core assert/deassert the chip select as it sees fit.
The chip select control inside the controller is buggy. It is supposed to
automatically assert the chip select based on the activity in the controller,
but it is buggy and doesn't work at all. So instead we elect to use GPIOs.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Let memory subsystem handle the error logging.
Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com>
Reviewed-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This patch moves the devm_spi_register_master below the initialization of the
runtime_pm. If done in the wrong order, the spi_register_master fails if any
probed slave devices issue SPI transactions.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Acked-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
It was observed that after module removal followed by insertion,
the SW mode chipselect is not properly set. Thus causing transfer
failure due to incorrect CS toggling.
Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This is to fix the SPI DMA transfer failure for speed less than 1M.
If using current DMA burst size setting (16), the Rx data bytes are
invalid due to each data byte is multiplied according to the burst
size setting.
Let's said supposedly we shall receive the following 18 bytes of data:
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18
Instead, the data bytes received consist of "16 bytes of '01' +
2 bytes of '02'" :
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 02 02
Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Extract the common parts of rspi_transfer_one(), rspi_rz_transfer_one(),
and qspi_transfer_out_in() into the new function rspi_common_transfer().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Enable DMA support for RSPI on r7s72100 (RZ/A1H).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Enable DMA support for QSPI on R-Car Gen2, for Single, Dual, and Quad SPI
Transfers.
Performance figures for reading from a QSPI FLASH driven at 24.375 MHz
on r8a7791/koelsch:
- Single: 1.1 Mbps PIO, 23 Mbps DMA
- Dual : 12.7 Mbps PIO, 48 Mbps DMA
- Quad : 13 Mbps PIO, 70 Mbps DMA
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
rspi_send_dma() and rspi_send_receive_dma() are very similar. Consolidate
into a single function rspi_dma_transfer(), and add missing checks for
dmaengine_submit() failures.
Both sg_table pointer parameters can be NULL, as RSPI supports TX-only
mode, and unidirectional DMA transfers will also be needed later for
Dual/Quad DMA support.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The DMA routines only need access to the scatter-gather tables inside the
spi_transfer structures, hence just pass those.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Refactor RSPI (on SH) DMA handling to make it reusable for other RSPI
implementations:
- Call the DMA routines after configuring the TX Mode bit and after
calling rspi_receive_init(), so these RSPI-specific operations can be
removed from the DMA routines,
- Absorb rspi_transfer_out_in() into rspi_transfer_one().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Use the SPI core DMA mapping framework instead of our own.
If available, DMA is used for transfers larger than the FIFO size
(8 or 32 bytes).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The SPI DMA core framework needs both RX and TX DMA to function. As a
preparation for converting the driver to use this framework, fall back to
PIO if no DMA channel or only one DMA channel is available.
This affects only RSPI, which could do DMA transfers for TX-only before.
RSPI-RZ and QSPI (at least for Single SPI Transfers) will need both RX and
TX DMA anyway.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The resource is know to exist, as rspi_probe() already mapped it.
Remove the test, and just pass the resource.
Pass the device pointer instead of the platform device pointer, as the
latter is no longer needed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Setup of the receive and transmit DMA channels is very similar, so let's
consolidate.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Fall back to PIO if DMA configuration failed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The various PIO loops are very similar. Consolidate into a single
function rspi_pio_transfer().
Both buffer pointers can be NULL, as RSPI supports TX-only mode, and
Dual/Quad SPI Transfers are unidirectional.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
RSPI needs dummy transfers to generate the SPI clock on receive.
RSPI-RZ and QSPI always do both transmit and receive.
Use the SPI core SPI_MASTER_MUST_RX/SPI_MASTER_MUST_TX infrastructure
instead of checking for the presence of buffers and providing dummy data
ourselves (for PIO), or providing a dummy buffer (for DMA).
rspi_receive_dma() now provides full duplex DMA transfers on RSPI, and is
renamed to rspi_send_receive_dma().
As the SPI core will always provide a TX buffer, the logic to choose
between DMA send and DMA send/receive in rspi_transfer_one() now has to
check for the presence of an RX buffer. Likewise for the DMA availability
tests in rspi_is_dma().
The buffer tests in qspi_transfer_one() are now always true, so they're
removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The 16-bit DMA support doesn't fit well within the SPI core DMA framework,
as it needs to manage its own double-sized temporary buffers, for handling
the interleaved data.
Remove it, as there is no in-tree board code that sets
rspi_plat_data.dma_width_16bit.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Since commit 8449fd76de ("spi: rspi: Merge
rspi_send_pio() and rspi_receive_pio()"), rspi_receive_init() is called
for transmit-only transfers too, while this is not needed.
Only call rspi_receive_init() when receiving, to preserve behavior on
RSPI on SH.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
In commit 7dd6278733 (spi/pxa2xx: Convert
to core runtime PM) master->auto_runtime_pm was set to true.
In this case pm_runtime_enable() must be called *before*
spi_register_master(), otherwise the kernel hangs with this error
message:
spi_master spi0: Failed to power device: -13
A similar fix, but for spi/hspi, was applied in
268d76430d.
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Signed-off-by: Mark Brown <broonie@linaro.org>
By default for every espi transfer, the rx_buf is placed right after the
tx_buf. This can lead to a buffer overflow when the size of both the TX
and RX data cumulated is higher than the allocated 64K buffer for the
transfer (this is the case when sending for instance a read command and
reading 64K back, please see:
http://article.gmane.org/gmane.linux.drivers.mtd/53411 )
This gets fixed by always setting the RX buffer pointer at the begining
of the transfer buffer.
[The driver shouldn't be doing the copy in the first place and instead
sending directly from the supplied buffer but this is at least not worse
than what's there -- broonie]
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Rejecting unsupported values of spi-tx-bus-width and spi-rx-bus-width
may break compatibility with future DTs. Just ignore them, falling back
to Single SPI Transfers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The calculation of the bit rate divider used a standard C division, which
rounds down the quotient. This may lead to a higher bitrate than requested.
Round up to avoid this.
E.g. on Koelsch, the SPI flash (configured for 30 MHz) was driven at 48.75
MHz. After this patch it's driven at a safe 24.375 MHz.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
