In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
In case when we have multiple devices connected to the
one SPI interface the initial state of CS gpios after
MCU reset is floating and it might be low that prevents us from
communicating between particular devices. Fix that by
initializing all provided cs gpios and setting them as inactive.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Add extra cs_gpios and num_cs_gpios members into
spi_context structure that will be used to
initialize all defined cs gpios during the driver
initialization using SPI_CONTEXT_CS_GPIOS_INITIALIZE macro.
While at it add a new spi_context_cs_configure_all
function that allows the user to configure
all available cs gpios in inactive mode.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
A couple of SPI drivers use CONFIG_KERNEL_INIT_PRIORITY_DEVICE
as init priority for driver initialization. Let's change
it to the dedicated CONFIG_SPI_INIT_PRIORITY to make it
compatible with other ones.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
The PM callback is no longer referenced as "pm_control" but
"pm_action_cb", so reflect this new naming on the callbacks.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Do not limit the length of the prepared transfer to the shorter of
provided TX and RX buffers if both are used. The SPIS peripheral
cannot handle scattered buffers anyway, so there is no point in
getting the common part of TX and RX buffers for a partial transfer,
like it is done for SPI and SPIM peripherals; everything what is
possible needs to be transferred in one shot. For the same reason,
there is no point in calling spi_context_buffers_setup() and using
the related part of the spi_context structure, hence the call is
removed and buffer pointers are used directly.
Also return an error if a requested transfer length exceeds the SPIS
peripheral hardware limit, instead of silently limiting the transfer
like it was done so far.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The FIU/UMA module in the NPCX chip provides an dedicated SPI interface
to access the SPI flash. This commit adds the driver support for it.
With this commit, the application can call the flash APIs
(via spi_nor.c) to access the internal flash of NPCX EC chips.
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Change-Id: I32bbf09f6e014b728ff8e4692e48151ae759e188
With the introduction of `EXPERIMENTAL` and `WARN_EXPERIMENTAL` in
Zephyr all drivers settings having `[EXPERIMENTAL]` in their
prompt has has been updated to include `select EXPERIMENTAL` so that
developers can enable warnings when experimental features are enabled.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Replaces the prefixes of gpio_matrix_in and gpio_matrix_out
to unify those function calls on all supported socs.
Signed-off-by: Glauber Maroto Ferreira <glauber.ferreira@espressif.com>
Convert all CS control logic to be based on the `gpio_dt_spec` member
instead of the standalone `port`, `pin` and `flags` members.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Co-authored-by: Jordan Yates <jordan.yates@data61.csiro.au>
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Co-authored-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Depending of the soc and SPI peripheral, the Frame-Format of the
SPI can be configured to support TI or Motorola protocol.
This is configured through a new DTS property.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Apply the same changes as the previous commit made in the spi_nrfx_spim
shim, to keep these two shims aligned.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
According to the nRF5340 PS, for 32 Mbps high-speed SPI using SPIM4,
drive configuration H0H1 must be used. The underlying nrfx_spim driver
does it properly in its initialization function, so change the shim to
(re)initialize the driver when the SPI configuration is to be changed
(only then the speed to use is known), to avoid the need of duplicating
the corresponding code in the shim itself.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
According to the nRF5340 PS, SPIM4 only supports 32 Mbps when
the application core is running at 128 MHz. This patch adds
the corresponding check.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
enable spi driver to support dspi edma
add support for shared dma mux spi port
for shared spi port we need judge the irq source
Signed-off-by: Hake Huang <hake.huang@oss.nxp.com>
After update of stm32 cube l1 V1.10.3,
SPI_CR2_FRF doesn't exist for all stm32L1 MCU,
thus LL_SPI_SetStandard() is also not defined for all stm32l1 MCU.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Max SPI chunk len was missing from the
implementation, causing SPI to hang up in some
conditions.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Instead of passing target states, use actions for device PM control.
Actions represent better the meaning of the callback argument.
Furthermore, they are more future proof as they can be suitable for
other PM actions that have no direct mapping to a state. If we compare
with Linux, we could have a multi-stage suspend/resume. Such scenario
would not have a good mapping when using target states.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
According to the documentation the OFF state has to be used when the
devices is fully turned off, ie, power removed. Most drivers were using
a sort of fall-through for all non-active states, leading to behaviors
not following the specifications.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Return -ENOTSUP if the requested state is not supported
- Remove redundant "noop style" functions.
- Use switch everywhere to handle requested state (not necessary in all
drivers, but better take off with consistency in place after current
changes).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The verb tense for the suspended state was not consistent with other
states. The likely reason: state was being used as a command/action.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The difference between low power and suspend states is a thin blur line
that is is not clear and most drivers have used indistinctly. This patch
converges to the usage of the suspend state for low power, since
contrary to the low power state, it is used by both system and runtime
device PM. The low power state is still kept, but its future is unclear
and needs some discussion.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM control function will only be called if the requested
state is different from the current one. A significant amount of drivers
were checking for state changes, now unnecessary. This patch removes all
this redundant logic.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since the state is no longer modified by the device PM callback, just
use the state value.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The callback is now invoked to set the device PM state in all cases, so
the usage of ctrl_command is redundant.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM subsystem already holds the device state, so there is no
need to keep duplicates inside the device. The pm_device_state_get has
been refactored to just return the device state. Note that this is still
not safe, but the same applied to the previous implementation. This
problem will be addressed later.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Busy check APIs now return boolean type. Due to that change, the
function names have also been adjusted. The common name pattern for
boolean check type APIs is "PREFIX_is_CONDITION". For example,
"pm_device_is_busy". pm_device_busy_check has been renamed to
pm_device_is_busy and pm_device_any_busy_check to pm_device_is_any_busy.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The following device busy APIs:
- device_busy_set()
- device_busy_clear()
- device_busy_check()
- device_any_busy_check()
were used for device PM, so they have been moved to the pm subsystem.
This means they are now prefixed with `pm_` and are defined in
`pm/device.h`.
If device PM is not enabled dummy functions are now provided that do
nothing or return `-ENOSYS`, meaning that the functionality is not
available.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
All the macro for dma-cells are now in the
include/drivers/dma/dma_stm32.h header file.
So the include/dt-bindings/dma/stm32_dma.h is no more
useful and removed from #include.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The macro to set the element of the dma-cells for each peripheral
are defined in the dma_stm32 header file
and used in the periph driver (as dma client)
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This adds support for controlling the SUBGHZSPI NSS line in STM32WL
devices. This is a special dedicated SPI port only connected to the
radio device internally, chip select happens through a bit in the PWR
module. Adding a special dt-property to identify the port, it all gets
built out on non-WL devices.
Deduplicate the existing dts bindings in the process, and add the new
one for the special spi with the new property.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
