These two functions were using the value of ctx->xx_len wrong, the unit
is in words, not bytes, but spi_context_count_xx_buf_lens was iterating
over the length of bytes, not words.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
There was a race condition where `lpspi_end_xfer` can be called multiple
times per transfer. There was the case where a TX interrupt gets
triggered without the RX interrupt being set, and TX finishes writing
its last byte. Then, `spi_context_rx_len_left() == 0` is true and
`lpspi_end_xfer` happens, but the RX interrupt is still active. Then,
when the RX interrupt happens, `lpspi_end_xfer` will get called again.
To fix that, the architecture was adjusted to only call `lpspi_end_xfer`
once no interrupts are active any more, and the disabling of the
interrupts gets used to signal the end of the TX and RX part.
Minor adjustments were necessary to use the interrupt enable signals for
this purpose; the TX irq handler had its internal order reversed,
otherwise it wasn't guaranteed that the physical transfer is finished
when we disable the interrupt.
Also, the code where the RX interrupt gets disabled had to be moved out
of the RX irq handler, because the RX interrupt also needs to be
disabled if RX is finished but no RX interrupt is currently active.
Signed-off-by: Martin Stumpf <finomnis@gmail.com>
Support SPI_HOLD_ON_CS flag in the CPU-based driver. To do this we will
set CONTC bit to continue previous command. Technically it may not be
necessary right now, and could just not clear CONT bit...
but in the future in the lpspi driver we
will decouple the config/init of a transfer from the SDK
and therefore have more control over TCR,
and when we write the TCR, we need to take CONTC bit into account
otherwise a new command will be made. So this approach is how
it should be handled in the driver going forward in my opinion, even
if it might be possible without this bit right now, I want to introduce
it's usage now.
This commit also does a minor refactor in the ISR and adds some comments
to make the strange CS behavior and strange handling code more clear to
future readers.
Also, make the early predicted SPI xfer end code only happen for spi
versions where it is necessary, since I think that code is really the
best we can do but might have a race condition, where possible the last
word is not finished sending when we end the xfer. So limit the
potential affect to v1 lpspi where the workaround is actually required
due to stalling behavior.
Lastly, set the LPSPI into master mode at active low in init, due to
it being the most common case, we want the SPI CS lines to be
initialized at init of driver. I don't think it's worth it to make it
configurable at this time, but in the future it could be if needed.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
The LPSPI does support word sizes such as 6 or 7, anything as small as 2
bits. So fix the checks and the math to allow for this in the driver.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Optimize the TX fill algorithm to have less interrupts by filling the TX
fifo as much as possible during each interrupt handle.
Before, the algorithm was just a very simple, fill the TX fifo with as
much from only the current buffer as possible, then send it and wait for
the next interrupt. Now the algorithm is to fill the TX fifo as much as
possible, even if it means reading from multiple buffers during the
interrupt.
This has the advantage from master mode of having less interrupts. And
it is very important for slave mode because the slave mode does not
control the pacing of the transfer and so therefore should fill as much
as possible whenever possible in order not to miss a deadline.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Since these drivers mainly do not use MCUX except for the configure
function (which will soon also be changed), change namespace prefix to
lpspi_ instead of spi_mcux_ to avoid confusion.
Also improve descriptions of kconfigs to clarify what they are for.
Not changing the kconfig names for now since they are user-facing.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Fixes wait for completion problems where the ISR was not sending
out TX NOP's when needed causing the transfer to timeout
Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
There is a bug here clearly which is that if there is some error in the
transceive function, it returns without releasing the context.
This should be fixed by properly handling the errors with a context release
before returning.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
For multi-byte word, there is clearly a bug in that the same byte is
written to each spot in the word instead of writing all the bytes
properly.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Fix the ASYNC DMA API on the lpspi driver and actually make the entire
driver go through that path. Rather than having an orthogonal
internally synchronous path we can just have both APIs go through the
same asynchronous path and just use wait_for_completion from spi context
to implement either sync or async.
Also make DMA driver default y if dependency (an lpspi having dmas
property) is met.
And lpspi_wait_tx_fifo_empty can be shared between drivers.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Reintroduce the fast path that skips reconfiguring if we use the same
configuration, this fixes regression that causes a lot of latency at the
start of repeated transfers. Unfortuantely need to find alternative
workaround for S32K3 in order to do this instead of module reset, so
disable skipping for that platform.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
There are two bugs that caused regression for S32:
First there is a silicon errata specifically for the mask version on
this board that causes FIFO flush to not work as expected. The
workaround is to do a module reset before each transfer.
Second there was a division error for word size > 1 byte. The division
should be rounded up, not down, otherwise there will be an infinite
interrupt loop because the TX fifo will not be written to but the TDR
interrupt enabled causes interrupt when TX fifo is empty.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
These two fields were not being used and were a relic of some
intermediate implementation, and forgot to be removed.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Change the driver behavior so that if the provided RX buffer set is
bigger than the TX buffer, we will read all the RX buffer and fill the
TX with NOPs. The SPI driver API does not say to do this, and my
original interpretation of the API was that the TX length controls the
entire transfer length, but this behavior might fit better with some de
facto expectations of in tree consumers.
Also add some robustness to the calculation of how many extra bytes to fill
when tx should be nops.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
For the CPU-based drivers, delete the old MCUX based RTIO driver and use
the default RTIO submit implementation instead.
Rationale:
- 300 LOC -> 1 LOC to maintain.
- MCUX SDK based driver cannot control the chip select for the transfer
properly, but the new spi_nxp_lpspi.c driver can. So this fixes the
bug with the PCS when using RTIO.
Also enable the default RTIO implementation for DMA based driver.
In the future a DMA based RTIO driver with custom implementation can be
designed, but for CPU based transfer, which is already not optimal
performance, code maintenance is more important. Only requirement is
asynchronous submit, which is accomplished by p4wq in rtio workq.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
To fix the native hardware chip select, we need to rewrite this driver
to not use the MCUX SDK handle abstraction, which does not fit the
zephyr use case.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
