The EOQ mode has a hardware limitation in that it stops the transmission
(including the deassertion of the chip select signal) once the host CPU
requests end-of-queue for a particular word in the TX FIFO.
And XSPI mode has a limitation in that we need a separate CMD FIFO entry
for the last byte in the buffer, where the chip select signal needs to
be deasserted. It's not a functional limitation, but it's rather clunky
and the fact that we need to halt the pipeline and write a single entry
to the TX FIFO whenever a buffer ends brings the throughput down when
transmitting small buffers.
So the idea here is to use EOQ's limitation in our favor when using XSPI
mode. Stop special-casing that final word in the buffer, and just kill
the chip select signal by issuing an EOQ for that last word. Now it can
be mixed in with all the other words in the current TX FIFO train.
A small trick here is that we still keep using the XSPI-specific
signaling via the CMDTCFQ interrupt in RSER, and not enabling the EOQ
interrupt, in order to avoid hardware weirdness (potential races with
separate interrupts being raised for CMDTCFQ and EOQ for what is in fact
the end of the same transmission). That is just theoretical, but it's
good to be cautious, and the EOQ interrupt isn't needed.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-12-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, a SPI transfer that is not multiple of the highest supported
word width (e.g. 4 bytes) will be transmitted as follows (assume a
30-byte buffer transmitted through a 32-bit wide FIFO that is 32 bytes
deep):
- First 28 bytes are sent as 7 words of 32 bits each
- Last 2 bytes are sent as 1 word of 16 bits size
But if the dspi_setup_accel function had decided to use a lower
oper_bits_per_word value (16 instead of 32), there would have been
enough space in the TX FIFO to fit the entire buffer in one go (15 words
of 16 bits each).
What we're actually trying to avoid is mixing word sizes within the same
run with the TX FIFO, since there is an erratum surrounding this, and
invalid data might get transmitted.
So this patch adds special cases for when the remaining length of the
buffer can be sent in one go as 8-bit or 16-bit words, otherwise it
falls back to the standard logic of sending as many bytes as possible at
the highest oper_bits_per_word value possible.
The benefit is that there will be one less CMDFQ/EOQ interrupt to
service when the entire buffer is transmitted during a single go, and
that will improve the overall latency of the transfer.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-11-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds logic in the driver to transmit SPI buffers that use
bits_per_word=8 with a higher bits_per_word count (multiple of 8).
Currently the following (most common) modes are implemented:
- 8 bits_per_word on 32-bit capable controllers
- 8 bits_per_word on 16-bit capable controllers
- 16 bits_per_word on 32-bit capable controllers
Transfers which are not accelerated are transferred with a hardware
bits_per_word value equal to the one of the SPI transfer.
The difference from just extending bits_per_word=32 at the spi_device
driver level is that endianness is different - the SPI core wants to
treat bits_per_word=32 buffers as arrays of u32 (i.e. words in host CPU
endianness). So to preserve endianness when clumping 8x4 bits into
32-bit words, one must perform conversion between CPU and standard (big)
endianness.
All appearances (both on the wire as well as in the buffers presented to
the peripheral driver) are preserved, just that accesses to the PUSHR
and POPR registers are now more efficient, since the same number of
reads/writes can now carry more data (2x more data on TX, 4x more data
on RX).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-10-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When it gets set, End Of Queue Flag halts the DSPI controller and forces
the chip select signal to deassert.
This operating mode is not ideal, but it is used for the DSPI
instantiations where there is no other notification from the controller
that the data in the FIFO has finished transmission. So in practice, it
means that transmitting buffers larger than the FIFO size will yield
unpredictable results.
The only controller that operates in EOQ mode is MCF5441X (Coldfire). I
would say that the way EOQ is used (and documented in the reference
manual, too) on this chip is incorrect, and I would personally migrate
it to TCFQ, but that's notably worse in terms of performance (it can
only use 1 entry of the 16-deep FIFO) and if this limitation didn't
bother any Coldfire DSPI user so far, it's likely that we just need to
throw an error for larger buffers to make sure that callers are aware
their transfers are getting truncated/split.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-7-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These function names are very generic and it is easy to get confused.
Rename them after the hardware register that they are accessing.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Their names are confusing, since dspi_pop_tx prepares a word to be
written to the PUSHR register, and dspi_push_rx gets a word from the
POPR register.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-5-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a useless operation, and if the driver needs to do that, there's
something deeply wrong going on.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-4-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This variable has been present since the initial submission of the
driver, and held, for some reason, the value of zero, to be sent on the
wire in the case there wasn't any TX buffer for the current transfer.
Since quite a while now, however, it isn't doing anything at all.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Reduce the if-then-else-if-then-else sequence to:
- a simple division in the case of bytes_per_word calculation
- a memcpy command with a variable size. The semantics of larger-than-8
xfer->bits_per_word is that those words are to be interpreted and
transmitted in CPU native endianness.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-2-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The A-011218 eDMA/DSPI erratum affects most of the older Layerscape SoCs
with DSPI, and its workaround is a bit intrusive.
After this patch, there are no users of TCFQ mode that don't also
support XSPI (previously there was LS2085A).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-7-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There's no reason to keep this .ptp_sts_supported property explicitly in
devtype_data, since it can be deduced from the operating mode alone.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-6-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
XSPI allows for 2 extra features:
- Command cycling (use a single TX command with more than 1 word in the
TX FIFO).
- Increased word size (from 16 bits to 32 bits)
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-5-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Get rid of the ifdef for Coldfire and make these hardware
characteristics part of dspi->devtype_data.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-4-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When used in Extended SPI mode on LS1021A, the DSPI controller wants to
have the least significant 16-bit word written first to the TX FIFO.
In fact, the LS1021A reference manual says:
33.5.2.4.2 Draining the TX FIFO
When Extended SPI Mode (DSPIx_MCR[XSPI]) is enabled, if the frame size
of SPI Data to be transmitted is more than 16 bits, then it causes two
Data entries to be popped from TX FIFO simultaneously which are
transferred to the shift register. The first of the two popped entries
forms the 16 least significant bits of the SPI frame to be transmitted.
So given the following TX buffer:
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 0x0 | 0x1 | 0x2 | 0x3 | 0x4 | 0x5 | 0x6 | 0x7 | 0x8 | 0x9 | 0xa | 0xb |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 32-bit word 1 | 32-bit word 2 | 32-bit word 3 |
+-----------------------+-----------------------+-----------------------+
The correct way that a little-endian system should transmit it on the
wire when bits_per_word is 32 is:
0x03020100
0x07060504
0x0b0a0908
But it is actually transmitted as following, as seen with a scope:
0x01000302
0x05040706
0x09080b0a
It appears that this patch has been submitted at least once before:
https://lkml.org/lkml/2018/9/21/286
but in that case Chuanhua Han did not manage to explain the problem
clearly enough and the patch did not get merged, leaving XSPI mode
broken.
Fixes: 8fcd151d26 ("spi: spi-fsl-dspi: XSPI FIFO handling (in TCFQ mode)")
Cc: Esben Haabendal <eha@deif.com>
Cc: Chuanhua Han <chuanhua.han@nxp.com>
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20191228135536.14284-1-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The API for PTP system timestamping (associating a SPI transaction with
the system time at which it was transferred) is flawed: it assumes that
the xfer->tx_buf pointer will always be present.
This is, of course, not always the case.
So introduce a "progress" variable that denotes how many word have been
transferred.
Fix the Freescale DSPI driver, the only user of the API so far, in the
same patch.
Fixes: b42faeee71 ("spi: Add a PTP system timestamp to the transfer structure")
Fixes: d6b71dfaee ("spi: spi-fsl-dspi: Implement the PTP system timestamping for TCFQ mode")
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20191227012417.1057-1-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dma_request_slave_channel() is a wrapper on top of dma_request_chan()
eating up the error code.
By using dma_request_chan() directly the driver can support deferred
probing against DMA.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191212135550.4634-8-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For many places in the spi drivers, using the new `spi_transfer_delay`
helper is straightforward.
It's just replacing:
```
if (t->delay_usecs)
udelay(t->delay_usecs);
```
with `spi_transfer_delay(t)` which handles both `delay_usecs` and the new
`delay` field.
This change replaces in all places (in the spi drivers) where this change
is simple.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-10-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In this mode, the DSPI controller uses PIO to transfer word by word. In
comparison, in EOQ mode the 4-word deep FIFO is being used, hence the
current logic will need some adaptation for which I do not have the
hardware (Coldfire) to test. It is not clear what is the timing of DMA
transfers and whether timestamping in the driver brings any overall
performance increase compared to regular timestamping done in the core.
Short phc2sys summary after 58 minutes of running on LS1021A-TSN with
interrupts disabled during the critical section:
offset: min -26251 max 16416 mean -21.8672 std dev 863.416
delay: min 4720 max 57280 mean 5182.49 std dev 1607.19
lost servo lock 3 times
Summary of the same phc2sys service running for 120 minutes with
interrupts disabled:
offset: min -378 max 381 mean -0.0083089 std dev 101.495
delay: min 4720 max 5920 mean 5129.38 std dev 154.899
lost servo lock 0 times
The minimum delay (pre to post time) in nanoseconds is the same, but the
maximum delay is quite a bit higher, due to interrupts getting sometimes
executed and interfering with the measurement. Hence set disable_irqs
whenever possible (aka when the driver runs in poll mode - otherwise it
would be a contradiction in terms).
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190905010114.26718-4-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With this patch, the "interrupts" property from the device tree bindings
is ignored, even if present, if the driver runs in TCFQ mode.
Switching to using the DSPI in poll mode has several distinct
benefits:
- With interrupts, the DSPI driver in TCFQ mode raises an IRQ after each
transmitted word. There is more time wasted for the "waitq" event than
for actual I/O. And the DSPI IRQ count can easily get the largest in
/proc/interrupts on Freescale boards with attached SPI devices.
- The SPI I/O time is both lower, and more consistently so. Attached to
some Freescale devices are either PTP switches, or SPI RTCs. For
reading time off of a SPI slave device, it is important that all SPI
transfers take a deterministic time to complete.
- In poll mode there is much less time spent by the CPU in hardirq
context, which helps with the response latency of the system, and at
the same time there is more control over when interrupts must be
disabled (to get a precise timestamp measurement, which will come in a
future patch): win-win.
On the LS1021A-TSN board, where the SPI device is a SJA1105 PTP switch
(with a bits_per_word=8 driver), I created a "benchmark" where I
periodically transferred a 12-byte message once per second, for 120
seconds. I then recorded the time before putting the first byte in the
TX FIFO, and the time after reading the last byte from the RX FIFO. That
is the transfer delay in nanoseconds.
Interrupt mode:
delay: min 125120 max 168320 mean 150286 std dev 17675.3
Poll mode:
delay: min 69440 max 119040 mean 70312.9 std dev 8065.34
Both the mean latency and the standard deviation are more than 50% lower
in poll mode than in interrupt mode, and the 'max' in poll mode is lower
than the 'min' in interrupt mode. This is with an 'ondemand' governor on
an otherwise idle system - therefore running mostly at 600 MHz out of a
max of 1200 MHz.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20191001205216.32115-1-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This change provides the dspi_slave_abort() function, which is a callback
for slave_abort() method of SPI controller generic driver.
As in the SPI slave mode the transmission is driven by master, any
distortion may cause the slave to enter undefined internal state.
To avoid this problem the dspi_slave_abort() terminates all pending and
ongoing DMA transactions (with sync) and clears internal FIFOs.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Link: https://lore.kernel.org/r/20190924110547.14770-3-lukma@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
When the driver is working in TCFQ/EOQ mode (i.e. interacts with the SPI
controller's FIFOs directly) the following sequence of operations
happens:
- The first byte of the tx buffer gets pushed to the TX FIFO (dspi->len
gets decremented). This triggers the train of interrupts that handle
the rest of the bytes.
- The dspi_interrupt handles a TX confirmation event. It reads the newly
available byte from the RX FIFO, checks the dspi->len exit condition,
and if there's more to be done, it kicks off the next interrupt in the
train by writing the next byte to the TX FIFO.
Now the problem is that the wait queue is woken up one byte too early,
because dspi->len becomes 0 as soon as the byte has been pushed into the
TX FIFO. Its interrupt has not yet been processed and the RX byte has
not been put from the FIFO into the buffer.
Depending on the timing of the wait queue wakeup vs the handling of the
last dspi_interrupt, it can happen that the main SPI message pump thread
has already returned back into the spi_device driver. When the rx buffer
is on stack (which it can be, because in this mode, the DSPI doesn't do
DMA), the last interrupt will perform a memory write into an rx buffer
that has been freed. This manifests as stack corruption.
The solution is to only wake up the wait queue when dspi_rxtx says so,
i.e. after it has processed the last TX confirmation interrupt and
collected the last RX byte.
Fixes: c55be30591 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing")
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190903105708.32273-1-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On platforms like LS1021A which use TCFQ mode, an interrupt needs to be
processed after each byte is TXed/RXed. I tried to make the DSPI
implementation on this SoC operate in other, more efficient modes (EOQ,
DMA) but it looks like it simply isn't possible.
Therefore allow the driver to operate in poll mode, to ease a bit of
this absurd amount of IRQ load generated in TCFQ mode. Doing so reduces
both the net time it takes to transmit a SPI message, as well as the
inter-frame jitter that occurs while doing so.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190822211514.19288-5-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dspi->devtype_data is under the total control of the driver. Therefore,
a bad value is a driver bug and checking it at runtime (and during an
ISR, at that!) is pointless.
The second "else if" check is only for clarity (instead of a broader
"else") in case other transfer modes are added in the future. But the
printing is dead code and can be removed.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190822211514.19288-4-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The DSPI interrupt can be shared between two controllers at least on the
LX2160A. In that case, the driver for one controller might misbehave and
consume the other's interrupt. Fix this by actually checking if any of
the bits in the status register have been asserted.
Fixes: 13aed23927 ("spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ")
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190822211514.19288-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the entire function depends on the SPI status register having the
interrupt bits asserted, then just check it and exit early if those bits
aren't set (such as in the case of the shared IRQ being triggered for
the other peripheral). Cosmetic patch.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190822211514.19288-2-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The two functions are loosely coupled through dspi->waitq, but
logically, dspi_transfer_one_message depends on dspi_interrupt in order
to complete. Move its definition above it so the I/O functions are
grouped closer together.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-13-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch puts variable declaration in the reverse order of their
length for cosmetic purposes.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-11-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adapts the spi-fsl-dspi driver to the API changes introduced in
commit 8caab75fd2 ("spi: Generalize SPI "master" to "controller"").
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-10-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Introduced in commit 9298bc7273 ("spi: spi-fsl-dspi: Remove
spi-bitbang") for less than obvious reasons, this assignment is
confusing and serves no purpose.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no code path for reaching 'return ret;' without it first being
assigned to an error code. Therefore the initialization with 0 is
pointless.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-8-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no point in surrounding an entire function block in an if
condition. Rather, exit early if the condition is false.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-7-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These are macros that accept 0 or 1 as argument (a boolean value). Their
use encourages the abuse of complex ternary operations inside their
argument list, which detracts from the code readability. Replace these
with simple if-else statements.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds the field definitions for the SPI_SR register. The SPI
status register is write-1-to-clear and this value is written at init
time.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-5-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch to using more idiomatic register field definitions, which makes
it easier to look them up in the datasheet. Cosmetic patch.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-4-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a cosmetic patch that changes nothing except makes sure the code
is aligned to the same column, which makes it easier to the eye.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20190818180115.31114-2-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something goes
wrong. Let's remove these prints with a simple semantic patch.
// <smpl>
@@
expression ret;
struct platform_device *E;
@@
ret =
(
platform_get_irq(E, ...)
|
platform_get_irq_byname(E, ...)
);
if ( \( ret < 0 \| ret <= 0 \) )
{
(
-if (ret != -EPROBE_DEFER)
-{ ...
-dev_err(...);
-... }
|
...
-dev_err(...);
)
...
}
// </smpl>
While we're here, remove braces on if statements that only have one
statement (manually).
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20190730181557.90391-42-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The NXP's Vybryd vf610 can work as a SPI slave device (the CS and clock
signals are provided by master).
It is possible to specify a single device to work in that mode. As we do
use DMA for transferring data, the RX channel must be prepared for
incoming data.
Moreover, in slave mode we just set a subset of control fields in
configuration registers (CTAR0, PUSHR).
For testing the spidev_test program has been used.
Test script for this patch can be found here:
https://github.com/lmajewski/tests-spi/blob/master/tests/spi/spi_tests.sh
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
On ColdFire mcf54418, using DSPI_DMA_MODE mode, spi transfers
at first boot stage are not succeding:
m25p80 spi0.1: unrecognized JEDEC id bytes: 00, 00, 00
The reason is the SPI_SR initial value set by the driver, that
is not clearing (not setting to 1) the RF_DF flag. After a tour
on the dspi hw modules that use this driver(Vybrid, ColdFire and
ls1021a) a better init value for SR register has been set.
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some SoC share one irq number between DSPI controllers.
For example, on the LX2160 board, DSPI0 and DSPI1 share one irq number.
In this case, only one DSPI controller can register successfully,
and others will fail.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes the dspi_eoq_write function used by the
ColdFire mcf5441x family. The 16 bit cmd part must be re-set at
each data transfer.
Also, now that fifo_size variables are used for eoq_read/write,
a proper fifo size must be set (16 slots for the ColdFire dspi
module version).
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Acked-by: Esben Haabendal <esben@haabendal.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Upper layer users of SPI device drivers may rely on 'actual_length',
so it is important that information is correctly reported. One such
example is spi_mem_exec_op() function that will fail if
'actual_length' of the data transferred is not what was requested. Add
necessary code to populate 'actual_length.
Cc: Mark Brown <broonie@kernel.org>
Cc: Sanchayan Maity <maitysanchayan@gmail.com>
Cc: Stefan Agner <stefan@agner.ch>
Cc: cphealy@gmail.com
Cc: linux-spi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Registers of DSPI should not be accessed before enabling its clock. On
Toradex Colibri VF50 on Iris carrier board this could be seen during
bootup as imprecise abort:
Unhandled fault: imprecise external abort (0x1c06) at 0x00000000
Internal error: : 1c06 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.39-dirty #97
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
Backtrace:
[<804166a8>] (regmap_write) from [<80466b5c>] (dspi_probe+0x1f0/0x8dc)
[<8046696c>] (dspi_probe) from [<8040107c>] (platform_drv_probe+0x54/0xb8)
[<80401028>] (platform_drv_probe) from [<803ff53c>] (driver_probe_device+0x280/0x2f8)
[<803ff2bc>] (driver_probe_device) from [<803ff674>] (__driver_attach+0xc0/0xc4)
[<803ff5b4>] (__driver_attach) from [<803fd818>] (bus_for_each_dev+0x70/0xa4)
[<803fd7a8>] (bus_for_each_dev) from [<803fee74>] (driver_attach+0x24/0x28)
[<803fee50>] (driver_attach) from [<803fe980>] (bus_add_driver+0x1a0/0x218)
[<803fe7e0>] (bus_add_driver) from [<803fffe8>] (driver_register+0x80/0x100)
[<803fff68>] (driver_register) from [<80400fdc>] (__platform_driver_register+0x48/0x50)
[<80400f94>] (__platform_driver_register) from [<8091cf7c>] (fsl_dspi_driver_init+0x1c/0x20)
[<8091cf60>] (fsl_dspi_driver_init) from [<8010195c>] (do_one_initcall+0x4c/0x174)
[<80101910>] (do_one_initcall) from [<80900e8c>] (kernel_init_freeable+0x144/0x1d8)
[<80900d48>] (kernel_init_freeable) from [<805ff6a8>] (kernel_init+0x10/0x114)
[<805ff698>] (kernel_init) from [<80107be8>] (ret_from_fork+0x14/0x2c)
Cc: <stable@vger.kernel.org>
Fixes: 5ee67b587a ("spi: dspi: clear SPI_SR before enable interrupt")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
It seems that the proper structure field to use in this particular
case is *regmap_pushr* instead of regmap.
Addresses-Coverity-ID: 1470126 ("Copy-paste error")
Fixes: 58ba07ec79 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Esben Haabendal <eha@deif.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the XSPI bit for devices configured for XSPI mode (currently LS1021A),
and thereby switch to extended SPI mode, allowing for SPI transfers using
from 4 to 32 bits per word instead of 4 to 16 bits per word.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This implements handling of split CMD and TX FIFO queues for XSPI when
running in TCFQ mode.
It should be simple to add it to EOQ mode also. Currently, EOQ mode is
only used with coldfire. So if coldfire DSPI supports XSPI, XSPI FIFO
handling should be added to EOQ mode also.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This prepares for adding support for extended SPI mode (XSPI), by extending
the regmap with the extra SREX and CTAREx registers.
An additional register map is made for allowing 16 bit access to CMD and TX
FIFO of the PUSHR register separately, which is also needed for XSPI mode
support.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark volatile registers to avoid caching bugs.
Note: SPI_MCR is marked volatile because of CLR_TXF and CLR_RXF bits.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The MCR register is not changed, so initialize it in dspi_init().
The exception is the CLR_TXF and CLR_RXF bits, which should be written to
before each transfer to make sure we start with empty FIFOs. With MCR
register now configured as volatile, the regmap_update_bits will do a real
read-modify-write cycle.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This extends the driver with support for all SPI framesizes from 4 to 16
bits, and adds support for per transfer specific bits_per_word, while at
the same time reducing code size and complexity.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify driver by avoiding counter wrapping by clearing transfer counter
on first SPI transfer per interrupt instead of tracking what it was before.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As of 92dc20d83a, transfer->cs_change has
been supported for non-last transfers, but not for last transfer.
This change brings handling of cs_change in line with the specification in
spi.h, implementing handling of transfer->cs_change for all transfers.
The value for CMD FIFO is precalculated with transfer->cs_change field
taken into account, allowing for CS de-activate between transfers and
keeping CS activated after last transfer.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Checking directly against pointer value should be at least as fast as doing
bitmasking and compare, so let's keep it simple.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The if statement just above this if/else statement triggers on the same
condition, and then invalidates it.
Signed-off-by: Esben Haabendal <eha@deif.com>
Acked-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver creates a number of const structures that it stores in the
data field of an of_device_id array.
The data field of an of_device_id structure has type const void *, so
there is no need for a const-discarding cast when putting const values
into such a structure.
Done using Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver as well as the controller support the SPI lsb first
mode. However, it's not possible to configure it e.g. when using
spidev. Adding this flag to mode_bits resolves the issue and lsb first
mode can be used.
Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Propagate error return from dspi_request_dma() into probe routine's
return.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to error handling in this function, it is likely that going to
'out_master_put' was expected here.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current DMA implementation was not handling the continuous selection
format viz. SPI chip select would be deasserted even between sequential
serial transfers.
Use existing dspi_data_to_pushr function to restructure the transmit
code path and set or reset the CONT bit on same lines as code path
in EOQ mode does. This correctly implements continuous selection format
while also correcting and cleaning up the transmit code path.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently dmaengine_prep_slave_single was being called with length
set to the complete DMA buffer size. This resulted in unwanted bytes
being transferred to the SPI register leading to clock and MOSI lines
having unwanted data even after chip select got deasserted and the
required bytes having been transferred.
While at it also clean up the use of curr_xfer_len which is central
to the DMA setup, from bytes to DMA transfers for every use.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
Buffers allocated with a call to dma_alloc_coherent should be
freed with dma_free_coherent instead of the currently used
devm_kfree.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current DMA implementation had a bug where the DMA transfer would
exit the loop in dspi_transfer_one_message after the completion of
a single transfer. This results in a multi message transfer submitted
with SPI_IOC_MESSAGE to terminate incorrectly without an error.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
Once dspi is used in uboot, the SPI_SR have been set by some value.
At this time, if kernel enable the interrupt before clear the
status flag, that will trigger the wrong interrupt.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The call sequence spi_alloc_master/spi_register_master/spi_unregister_master
is complete; it reduces the device reference count to zero, which and results
in device memory being freed. The subsequent call to spi_master_put is
unnecessary and results in an access to free memory. Drop it.
Fixes: 9298bc7273 ("spi: spi-fsl-dspi: Remove spi-bitbang")
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
clk_prepare_enable() may fail, so we should better check its
return value and propagate it in the case of failure.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
of_match_device could return NULL, and so cause a NULL pointer
dereference later.
For fixing this problem, we use of_device_get_match_data(), this will
simplify the code a little by using a standard function for
getting the match data.
Reported-by: coverity (CID 1324129)
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
of_id->data is const, so instead of casting the pointer to drop its
const status, this patch constify the devtype_data pointer.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There are use cases when chip select should be triggered between transfers
in single SPI message. Current implementation does this only on last
transfer in message ignoring cs_change value provided in current transfer.
Signed-off-by: Andrey Vostrikov <andrey.vostrikov@cogentembedded.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Calculate and update max speed from bus clock for SoCs
using DSPI IP.
The bus clock factor's are taken from the data sheets
of respective SoCs.
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
DSPI instances in Vybrid have a different amount of chip selects
and CTARs (Clock and transfer Attributes Register). In case of
DSPI1 we only have 2 CTAR registers and 4 CS. In present driver
implementation CTAR offset is derived from CS instance which will
lead to out of bound access if chip select instance is greater than
CTAR register instance, hence use single CTAR0 register for all CS
instances. Since we write the CTAR register anyway before each access,
there is no value in using the additional CTAR registers. Also one
should not program a value in CTAS for a CTAR register that is not
present, hence configure CTAS to use CTAR0.
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI core makes sure that transfer speed is always set so code here writes
the same register with the same value twice. Code has been doing this from
the beginning.
This looks to me some sort of copy paste error so I'm removing the second
write. If this is not the case we can bring it back with a comment.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In current driver, we increase actual_length in the following way:
message->actual_length += dspi_xxx_transfer()
It has two defects.
First, transmitting maybe in process when the function call finished and
we don't know the transmitting result in this moment.
Secondly, the last sentence in function before returning is accessing the
SPI register and trigger the data transmitting. If we enable interrupt,
interrupt may be generated before function return and we also have the same
sentence "message->actual_length += dspi_xxx_transfer()"
in the IRQ handler.
And usually dspi_xxx_transfer will trigger a new IRQ.
The original dspi_xxx_transfer call may return when no new IRQ generate.
This may mess the variable spi_message->actual_length.
Now we increase the variable in the IRQ handler and only when we get the
TCF or EOQ interrupt
And we get the transmitted data length from the SPI transfer counter
instead of the function return value.
Signed-off-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DSPI module has two optional interrupts when complete data transfer.
One is EOQ interrupt, the other one is TCF interrupt.
EOQ indicates a queue of data frame has been transmitted.
TCF indicates a frame has been transmitted.
This patch enable support TCF mode.
Driver binds a correct interrupt mode to every compatible string.
User should use the correct compatible string in the dts node.
Signed-off-by: Haikun Wang <haikun.wang@freescale.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>
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>
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>
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>
Move the check for spi->bits_per_word
before allocation, to avoid memory leak.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DSPI module need cs change information in
a spi transfer. According to cs change, DSPI
will give last data the right flag. Bitbang
provide cs change behind the last data in
a transfer. So DSPI can not deal the last
data in every transfer properly, so remove
the bitbang in the driver.
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_* API was supposed to be used only in probe function call.
Memory is allocated at 'probe' and free automatically at 'remove'.
Usage of devm_* functions outside probe sometimes leads to memory leak.
Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead.
Also add the dspi_cleanup function to free the controller data upon
cleanup.
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
There are only 4 CTAR registers (CTAR0 - CTAR3) so we can only use the
lower 2 bits of the chip select to select a CTAR register.
SPI_PUSHR_CTAS used the lower 3 bits which would result in wrong bit values
if the chip selects 4/5 are used. For those chip selects SPI_CTAR even
calculated offsets of non-existing registers.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Since we are using regmap framework's internal locks, so the
lock_arg for dspi_regmap_config is redundant here.
This patch just remove it, and then the dspi_regmap_config could
be const type.
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
