As platform_get_irq_byname() now prints an error when the interrupt
does not exist, scary warnings may be printed for optional interrupts:
renesas_spi e6b10000.spi: IRQ rx not found
renesas_spi e6b10000.spi: IRQ mux not found
Fix this by calling platform_get_irq_byname_optional() instead.
Remove the no longer needed printing of platform_get_irq errors, as the
remaining calls to platform_get_irq() and platform_get_irq_byname() take
care of that.
Fixes: 7723f4c5ec ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20191016143101.28738-1-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
Process handling QSPI when transmit/receive at qspi_trigger_transfer_out_in() as follows:
Setting the trigger, is the number of bytes in the FIFO buffer to determine
when there is an interrupt. Then check if the value of triggering number is
32-bytes or 1-byte, there will be corresponding processing
Handling (if (n == QSPI_BUFFER_SIZE) esle) this is unnecessary, leads to the
same processing of data transmission or reception, The difference here are with
ret = rspi_wait_for_tx_empty(rspi);
ret = rspi_wait_for_rx_full(rspi);
When the nummber trigger is 32 bytes, we only write into FIFO when the FIFO is completely empty
(interrupt transmission), and only receive if FIFO is full of 32 bytes of data.
In the case of a nummber trigger that is 1 byte, in principle we still need to process
rspi_wait_for_tx_empty/full so that FIFO is empty only with the amount of data we need to write to
or equal to the number of bytes we need to receive, There is currently no processing of this.
And in the current case with this patch, at this time it only needs at least 1 byte received in
FIFO that has interrupt received, or FIFO at least 1bytes free can be written into FIFO,
This patch therefore does not affect this processing.
So we need to eliminate unnecessary waste processing (if (n == QSPI_BUFFER_SIZE) esle),
more precisely in waiting for FIFO status.
The same with handling in qspi_transfer_out()/qspi_transfer_in().
Signed-off-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
Signed-off-by: Mark Brown <broonie@kernel.org>
While the sequencer is reset after each SPI message since commit
880c6d114f ("spi: rspi: Add support for Quad and Dual SPI
Transfers on QSPI"), it was never reset for the first message, thus
relying on reset state or bootloader settings.
Fix this by initializing it explicitly during configuration.
Fixes: 0b2182ddac ("spi: add support for Renesas RSPI")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas RSPI/QSPI driver performs SPI controller register
initialization in its spi_operations.setup() callback, without calling
pm_runtime_get_sync() first, which may cause spurious failures.
So far this went unnoticed, as this SPI controller is typically used
with a single SPI NOR FLASH containing the boot loader:
1. If the device's module clock is still enabled (left enabled by the
bootloader, and not yet disabled by the clk_disable_unused() late
initcall), register initialization succeeds,
2. If the device's module clock is disabled, register writes don't
seem to cause lock-ups or crashes.
Data received in the first SPI message may be corrupted, though.
Subsequent SPI messages seem to be OK.
E.g. on r8a7791/koelsch, one bit is lost while receiving the 6th
byte of the JEDEC ID for the s25fl512s FLASH, corrupting that byte
and all later bytes. But until commit a2126b0a01 ("mtd:
spi-nor: refine Spansion S25FL512S ID"), the 6th byte was not
considered for FLASH identification.
Fix this by moving all initialization from the .setup() to the
.prepare_message() callback. The latter is always called after the
device has been runtime-resumed by the SPI core.
This also makes the driver follow the rule that .setup() must not change
global driver state or register values, as that might break a transfer
in progress.
Fixes: 490c97747d ("spi: rspi: Add runtime PM support, using spi core auto_runtime_pm")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
As of commit 8caab75fd2 ('spi: Generalize SPI "master" to
"controller"'), the old master-centric names are compatibility wrappers
for the new controller-centric names.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When interrupted, wait_event_interruptible_timeout() returns
-ERESTARTSYS, and the SPI transfer in progress will fail, as expected:
m25p80 spi0.0: SPI transfer failed: -512
spi_master spi0: failed to transfer one message from queue
However, as the underlying DMA transfers may not have completed, all
subsequent SPI transfers may start to fail:
spi_master spi0: receive timeout
qspi_transfer_out_in() returned -110
m25p80 spi0.0: SPI transfer failed: -110
spi_master spi0: failed to transfer one message from queue
Fix this by calling dmaengine_terminate_all() not only for timeouts, but
also for errors.
This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed
by CTRL-C.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
If the SPI queue is running during system suspend, the system may lock
up.
Fix this by stopping/restarting the queue during system suspend/resume,
by calling spi_master_suspend()/spi_master_resume() from the PM
callbacks. In-kernel users will receive an -ESHUTDOWN error while
system suspend/resume is in progress.
Based on a patch for sh-msiof by Gaku Inami.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use enum dma_transfer_direction as required by dmaengine_prep_slave_sg
instead of enum dma_data_direction. This won't change behavior in
practice as the enum values are equivalent.
This fixes two warnings when building with clang:
drivers/spi/spi-rspi.c:538:26: warning: implicit conversion from enumeration
type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
rx->sgl, rx->nents, DMA_FROM_DEVICE,
^~~~~~~~~~~~~~~
drivers/spi/spi-rspi.c:558:26: warning: implicit conversion from enumeration
type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
tx->sgl, tx->nents, DMA_TO_DEVICE,
^~~~~~~~~~~~~
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
The R-Car Gen2 Hardware User Manual Rev. 2.00 states:
If the master/slave mode select bit (MSTR) is modified while the SPI
function enable bit (SPE) is set to 1 (that is, this module is
enabled), the subsequent operation cannot be guaranteed.
Hence do not set SPCR_SPE when setting SPCR_MSTR, just like the
.set_config_register() implementations for other RSPI variants do.
Note that when booted from QSPI, the boot loader will have set SPCR_MSTR
already, hence usually the bit is never modified by the Linux driver.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the of_device_get_match_data() helper instead of open coding.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch replaced "n" by "len" bytes of data in qspi_transfer_in() and
qspi_transfer_out() function. This will make improving readability.
Signed-off-by: DongCV <cv-dong@jinso.co.jp>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
In qspi_transfer_in(), when receiving the last n (or len) bytes of data,
one bogus byte was written in the receive buffer.
This code leads to a buffer overflow.
"jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
at 0x03b40000: 0x1900 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
at 0x03b40004: 0x000c instead"
The error message above happens when trying to mount, unmount,
and remount a jffs2-formatted device.
This patch removed the bogus write to fixes: 3be09bec42
"spi: rspi: supports 32bytes buffer for DUAL and QUAD"
And here is Geert's comment:
"spi: rspi: Fix bogus received byte in qspi_transfer_in()
When there are less than QSPI_BUFFER_SIZE remaining bytes to be received,
qspi_transfer_in() writes one bogus byte in the receive buffer, possibly
leading to a buffer overflow.
This can be reproduced by mounting, unmounting, and remounting a
jffs2-formatted device, causing lots of warnings like:
"jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
at 0x03b40000: 0x1900 instead"
Remove the bogus write to fix this. "
Signed-off-by: DongCV <cv-dong@jinso.co.jp>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Printing an error on memory allocation failure is unnecessary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
The newly introduced rspi_pio_transfer_in_or_our() function must
take either a valid 'rx' or 'tx' pointer, and has undefined behavior
if both are NULL, as found by 'gcc -Wmaybe-unintialized':
drivers/spi/spi-rspi.c: In function 'rspi_pio_transfer_in_or_our':
drivers/spi/spi-rspi.c:558:5: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The analysis of the function is correct in principle, but the code
is currently safe because both callers always pass exactly one
of the two pointers.
Looking closer at this function shows that having a combined
method for rx and tx here actually increases the complexity
and the size of the file. This simplifies it again by keeping
the two separate, which then ends up avoiding that warning.
Fixes: 3be09bec42 ("spi: rspi: supports 32bytes buffer for DUAL and QUAD")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch supports 32bytes of buffer for DUAL and QUAD in QSPI by
Using Transmit/Receive Buffer Data Triggering Number.
In order to improve the DUAL and QUAD's performance of SPI
while transferring data in PIO mode, it sends/receives each 32bytes
data instead of each byte data as current situation.
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Signed-off-by: Mark Brown <broonie@kernel.org>
When you leave the clock divider at 0, 130kHz is the lowest you can go.
Also, by adjusting the clock divider you can get more accurate resolutions
for clock speeds lower than 16MHz. This patch uses the clock divider as
part of the bit rate setup.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
qspi_set_send_trigger() returns an unsigned value, so make it return
"unsigned int".
Update the loop variables qspi_trigger_transfer_out_int() to match the
above.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Just use "ret" instead, for consistency with other similar functions.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
To reduce complexity of code, drop "ret" then qspi_transfer_out_in function
should return the value of "qspi_trigger_transfer_out_in" directly.
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
The name of "qspi_trigger_transfer_out_int" function should be
"qspi_trigger_transfer_out_in" without "t".
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
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>
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>
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>
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>
Current rspi sets dma_slave_config :: slave_id field for DMAEngine,
but it is no longer needed. Let's remove it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Add support for QSPI in:
- r8a7792 (R-Car V2H)
- r8a7793 (R-Car M2-N)
- r8a7794 (R-Car E2)
r8a7791 is now called "R-Car M2-W".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
The new Renesas R-Car Gen2 DMA Controller driver (rcar-dmac) requires
explicit configuration of the DMA slave bus width.
Hardcode the DMA transfer size to 1 byte for both directions, as that's
the only supported configuration (16-bit DMA support was removed in
commit 9c5de2c175 ("spi: rspi: Remove
unused 16-bit DMA support")).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Use the devm_kasprintf() helper function instead of open coding
error-prone buffer handling and string formatting.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
If dmaengine_prep_slave_sg() or dmaengine_submit() fail, we may leak
unused DMA descriptors.
As per Documentation/dmaengine.txt, once a DMA descriptor has been
obtained, it must be submitted. Hence:
- First prepare and submit all DMA descriptors,
- Prepare the SPI controller for DMA,
- Start DMA by calling dma_async_issue_pending(),
- Make sure to call dmaengine_terminate_all() on all descriptors that
haven't completed.
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
As typically a shmobile SoC has less DMA channels than devices that can use
DMA, we may want to prioritize access to the DMA channels in the future.
This means that dmaengine_prep_slave_sg() may start failing arbitrarily.
Handle dmaengine_prep_slave_sg() failures gracefully by falling back to
PIO.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
rspi_release_dma() doesn't need access to any fields in the driver private
data, except for the pointer to the SPI master object. Hence just pass the
needed pointer.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@linaro.org>
Introduced by commit 8b983e90ea ("spi: rspi:
Extract rspi_common_transfer()"), which removed its users.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
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>
