Updated buffer length variables to be size_t as they need to be able to
represent the maximum buffer size which is 4092.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
This stupid errata will not leave me alone, here is another bandaid to
deal with an issue where an extra byte was being sent on version 1
LPSPIs due to the algorithm of filling NOPs when only RX is left was not
expecting the situation where the LPSPI actually consumed everything
from the fifo but is not sending it due to this ridiculous stalling errata.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
The buf_len parameter of lpspi_fill_tx_fifo is supposed to be bytes, so
we do not need to convert it. This could cause an issue if the end of
the buffer is less bytes than the word size.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Fixing some issues with the TX fifo fill logic in two places:
First in the normal fill function, it didn't take into account a
situation where the TX fifo is already partially filled. This currently
doesn't cause a problem because the driver is written in a way that the
watermark is always 0 for TDF, but in case the watermark were anything
else it would cause a problem.
Second, when filling the TX fifo with NOPS in order to clock the rest of
the RX in from the bus, the calculation regarding the current TX fifo
length was just wrong and was leading to a bug in some cases where there
was a subtraction underflow and billions of NOPs were being filled.
Also, there could be a problem where a few extra NOPs are put in the TX
fifo if we don't count what we already have in the TX fifo, so fixing
that as well.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
There is no need to update the tx context in interrupt instead of
directly after the fill, this just makes the code more complex. Also,
the spi context header already handled iterating over buffers so we can
remove that code too.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Since the LPSPI drivers no long use MCUX at all, remove the MCUX
branding, to avoid confusion. In the future if an implementation uses
the MCUX SDK driver, it should specifically be called by MCUX in the
name.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
For optimization purpose, remove calls to SDK. Since we know exactly
what we want, this results in smaller code size.
Also, this code calculates the SCK parameters more efficiently than the
SDK driver did it by using a binary (instead of linear) search.
Lastly, remove call to LPSPI_Reset in the init call and replace with
native driver code, and remove inclusion of SDK header.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Instead of waiting forever and potentially allowing infinite loop on
ISR, wait some arbitrary amount of cycles to error out if it isn't
happening. Still make this configurable for debugging purposes.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Since I expect that the drivers will need to read this version ID maybe
multiple times, instead of repeatedly doing so over the peripheral bus,
it is probably worth it to store a byte in RAM representing this
version. The behavior of the LPSPI is fairly significantly different
between versions. Not enough to warrant separate drivers but enough to
need a few workarounds or different code branches depending on this.
Also, the interrupt based driver is currently using a wrong macro to
read this, and that is a bug.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
Clarify at the top of the common lpspi file what is the purpose of the
file to be clear to future developers that this file is not supposed to
make any assumption about a particular implementation of the zephyr API
using the LPSPI, because I imagine it could be very likely that more
lpspi implementation will be done in the future to make different
tradeoffs than the current two. Also the current two are different
enough that we should avoid making assumptions even if they currently
hold for both because they might not always, as things change.
We should disable interrupt events while configuring the LPSPI
regardless of implementation. The specific implementation should enable
the interrupts it needs on its own transceive implementation.
Also clarify and simplify some code in the configure function. Namely,
we no longer need to check if we are already configured to write to
registers because a recent commit made it so that we clock the
peripheral from the zephyr driver init instead of upon the MasterInit
call on the SDK. There is also a redundant CR write which I have removed.
Signed-off-by: Declan Snyder <declan.snyder@nxp.com>
When reconfiguring the SSP, some changes do not immediately take effect
in particular changes to the clock polarity are not applied. Disabling
and re-enabling the SSP forces the new configuration to take effect
immediately.
Signed-off-by: George Norton <george_norton_uk@hotmail.com>
Update the source_data and dest_data sizes with the frame size
in bytes before performing the transfer.
With these changes, we can handle cases where the buffers switch
between 8-bit and 16-bit modes.
Signed-off-by: Fabrice DJIATSA <fabrice.djiatsa-ext@st.com>
Workaround to avoid getting the -EFAULT (14) error when running
the test_spi_word_size_x (x = 7, 9, 24) test cases:
Since these testcase configurations aren't supported, update
the error type to ENOTSUP to allow skipping the test cases using ztest.
Signed-off-by: Fabrice DJIATSA <fabrice.djiatsa-ext@st.com>
It is not an error if the clock source is already enabled. This
may happen if a bootloader has used the peripheral and not
de-initialized it before booting the application.
Signed-off-by: Aksel Skauge Mellbye <aksel.mellbye@silabs.com>
The function FLEXIO_SPI_MasterTransferNonBlocking has a bug when
works in CS continuous mode. In this mode, both RX and TX
interrupts are enabled, they share the same IRQ line.
In the ISR, the RX event and TX event are not handled well,
so a short delay in ISR is needed.
The function FLEXIO_SPI_MasterTransferNonBlocking issue is fixed,
the delay in ISR can be removed.
Signed-off-by: Jason Yu <zejiang.yu@nxp.com>
Currently there is a mismatch between the naming of the hardware and
the drivers targetting the hardware. nrf2_ is used instead of
the actual bindings names, like nrf2_audiopll instead of
nrfs_audiopll. This makes it hard to map drivers to the hardware
they are targetting.
There is historical reason for some of this, namely the same binding
name was used for different hardware, which is why nrf2_ was used
on newer platforms. This is no longer the case though, so drivers
and configs can be named according to the hardware without conflict.
Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
Reset the SPI peripheral to its default state
and register values on init by setting its SWRST bit.
This is important since the driver assumes that certain
registers are at their default values.
Signed-off-by: Pete Dietl <petedietl@gmail.com>
The sam0 SPI driver does not ensure that it clears the 32-bit extension
option during init. The 32-bit extension option, which comprises of a field
in the CTRLC register and the LENGTH register enables better bus
utilization by allowing 32-bit writes to the SPI DATA register
(as opposed to the usual 8-bit writes). The driver breaks down if this
option is enabled by causing each intended byte of output to become
four bytes. We fix this by explicitly disabling the 32-bit extension
option in init.
Signed-off-by: Pete Dietl <petedietl@gmail.com>
To determine whether device runtime PM is enabled on a device, use
`pm_device_runtime_is_enabled`. This results in the same behaviour when
`CONFIG_PM_DEVICE_RUNTIME=n`, but properly controls the clocks on a
per-instance basis when `CONFIG_PM_DEVICE_RUNTIME=y`.
Signed-off-by: Jordan Yates <jordan@embeint.com>
To convey the correct data size, use the 'data->dfs' value instead
of '1' when moving the SPI context to the next buffer.
Signed-off-by: Andreas Wolf <awolf002@gmail.com>
Initial commit for SPI driver support on RSK_RX130@512KB board
with RSPI module
Signed-off-by: Duy Nguyen <duy.nguyen.xa@renesas.com>
Signed-off-by: Minh Tang <minh.tang.ue@bp.renesas.com>
Replace UTIL_AND(DT_INST_NODE_HAS_PROP(... construction with the
DT_INST_PROP_OR helper macro.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
This is a follow-up to commit a068709171.
As the SPIM_REQUESTS_CLOCK() macro changed the type of its parameter,
all of the calls to it need to be updated accordingly. Also the call to
DT_NODELABEL() needs to be removed from that macro as DT_CLOCKS_CTLR()
already returns a node identifier.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Several drivers checked for the presense and availability of data cache
through Kconfig symbol. This is supported according to the current
documentation, but the symbol DCACHE masks two types of cache devices: arch
and external caches. The latter is present on some Cortex-M33 chips, like
the STM32U5xx. The external dcache is bypassed when accessing internal
SRAM and only used for external memories.
In commit a2dd232410 ("drivers: adc: stm32: dma support") the rationale
for gating dcache for adc_stm32 behind STM32H7X is only hinted at, but
reason seems to be that it was the only SOC the change was tested on. The
SOC configures DCACHE=y so it is most likely safe to swap the SOC gate for
DCACHE.
The DCACHE ifdefs are now hidden inside the shared stm32_buf_in_nocache()
implementation.
Signed-off-by: Henrik Lindblom <henrik.lindblom@vaisala.com>
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>
The unit of spi_context's tx_len and rx_len is byte instead of frame.
Thus, in spi_context_update_tx(), the value of ctx->tx_len should be
reduced by (len * dfs).
Also to fix the update of ctx->tx_len in spi_context_update_rx().
Signed-off-by: cyliang tw <cyliang@nuvoton.com>
Remove the auto setting of the external spi clock if its not there,
also fix the calculation of calucation the spi divisor value.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
The PM Device callbacks is rather unimplemented. There currently is
no device agnostic clock management api (yet), and the pinctrl isn't
fully implemented in this driver. Remove it all.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
This adds the missing fifo config from the dts which was missed in
the initial revision. This also adds the spi rtio fallback api.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Replace semaphores with proper atomic flags when used without
multithreading enabled.
Signed-off-by: Michal Kozikowski <michal.kozikowski@nordicsemi.no>
The nrxf_spim driver currently resumes itself for the duration of
a transfer, however, in case SPI_LOCK_ON is used, the driver needs
to keep itself resumed until spi_release() is called. Currently,
this results in unbalanced suspend as the bus puts itself both
after transaction is done, and when spi_release() is called.
This patch makes the driver check if SPI_LOCK_ON is set once
transaction is complete, if yes, selv get one more time to
account for the two puts which will follow.
Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
This dependency was always there but not explicitly defined.
By adding the explicit dependency it becomes more obvious
what is wrong when SPI is enabled but GPIO disabled.
This was found when building `samples/bluetooth/peripheral`
for `nrf54l15dk/nrf54l15/cpuapp` with `CONFIG_GPIO=n`.
Before we got:
- A linker error in `spi_nrfx_common.c` failing
to reference some nrfx_gpiote APIs.
- A linker error in `spi_nrfx_spim.c` failing to reference
the GPIO dts entry.
Now we will get a warning of that GPIO is not enabled
With this it becomes more obvious that SPI driver is enabled by
default because of the external flash mounted on the DK.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
SPI driver for Microchip MEC5 HAL based QSPI controller. QSPI
hardware supports full duplex, dual, and quad operation. MEC5
QSPI controller also includes three local DMA channels per
direction to off load firmware. The driver API supports full
or half-duplex. Due to QSPI hardware not supporting one wire
half-duplex, this driver supports full-duplex only. QSPI hardware
design requires it to control chip select and current hardware
supports up to two chip selects. Zephyr's SPI DT macros store the
child SPI device's reg properity as the "slave" member of the SPI
configuration structure. The driver uses the "slave" value as the
chip select. Additional timing settings specific to SPI flash devices
are in a new SPI device YAM file: "microchip,mec5-qspi-device.yaml"
which includes the standard "spi-device.yaml". If the new YAML is not
used, the QSPI controller will use default timing values for chip
select and I/O line taps.
Signed-off-by: Scott Worley <scott.worley@microchip.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>
In case the SPI transaction has SPI_HOLD_ON_CS set, we need to keep
SPI resumed until spi_release() is called. This is required as we
now need to keep the CS GPIO port resumed until transaction is
complete.
Suspending CS GPIO is not allowed from ISR in some cases (H20 fast
GPIO instance) so we have to defer CS GPIO suspend to some thread
context (put_async or spi_release()).
Signed-off-by: Bjarki Arge Andreasen <bjarki.andreasen@nordicsemi.no>
