Only run the `uninit` function if the SPI instance has previously been
configured. This stops an assertion in the HAL drivers from triggering
due to running `uninit` without a previous `init`.
Fixes#42299.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
This corrects the following:
1. The priority of type cast is lower than member access. So don't need
the redundant parentheses.
2. The macro should be added to the parentheses.
Signed-off-by: Wealian Liao <WHLIAO@nuvoton.com>
The commit 44679c7bd8 introduced this
duplicated declaration of the local variable data.
This commit fixes this issue.
Fixes#42117
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
Some drivers explicitely casted data/config from void * to the
corresponding type. However, this is unnecessary and, in many drivers it
has been misused to drop const qualifier (refer to previous commits).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Replace all get_dev_data()/get_dev_config() accessor utilities with
dev->data and dev->config.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Stop using redundant DEV_DATA/DEV_CFG macros and use dev->data
and dev->config instead.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to align with macros used to obtain a device reference (e.g.
DEVICE_DT_GET), align the PM macros to use "GET" instead of "REF". This
change should have low impact since no official release has gone out yet
with the "REF" macros.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The SAM spi driver depends on GPIO driver to work. It seems that this
dependency chain it is not handled. This select GPIO driver when SPI
driver is enabled. It rework GPIO and SPI Kconfig to select driver by
devicetree and drop entries at Kconfig.defconfig.series file.
Fixes#41525
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
the stm32 spi drivers now takes the DTS frame_format property
from the include/ drivers/spi.h
It will be possible to select the Motorola (default)
or TI from the DTS entry of the device,
when soc supports it, else a run time error is raised.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Subghzspi instances cannot have any pinctrl configs,
they are blacklisted by the dts binding. This caused an
initialization failure of the spi_ll_stm32 driver for
subghzspi instance because no "default" pinctrl was found.
This commit solves the problem by skipping the pinctrl setup
for subghzpi devices. The use_subghzpi_nss property is used
to identify a subghzspi device, as this is a required boolean
property only available in the subghzspi binding this is a
perfect indicator for such instances.
Signed-off-by: Alexander Mihajlovic <a@abxy.se>
This patch controls the SPI of the stm32H7 mcu when using
the DMA transfer. Starting and ending the transfer
are specific according to the RefMan.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
A generic function is used to give the register address to the DMA.
The SPI of the stm32H7 serie has two data registers for Tx and Rx
When the DMA is getting the address it differs between Rx and Tx.
As the stm32cube/stm32h7xx/drivers/include/stm32h7xx_ll_spi.h
has no such LL functions, the register address is get direclty.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The spi_stm32_complete() is checking spi flags which are valid when the
intance is still enable: disable afterwards. No more need to disable
the DMA transfer then
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Defines a function to control the spi busy state during DMA transfer.
After the DMA Tx, the spi might still have some data to Transmit.
The driver must wait for the SPI Tx before sending the next packet.
This is not required for the Rx part as the DMA Rx is already done.
Some mcus like stm32H7 have a TX complete bit, other must wait for the
TXE and BSY line.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The PINCTRL_DT_(INST_)DEFINE macros already defined the trailing ;,
making its usage inconsistent with other macros such as
DEVICE_DT_DEFINE.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Instead of checking the SPI register flags, the spi_ll_stm32.h
has dedicated functions for that purpose.
They are abstracting the STM32 registers of SPI instance.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add driver for MEC172x QMSPI with local DMA(LDMA). The driver
support SPI asynchronous operation.
Signed-off-by: Jay Vasanth <jay.vasanth@microchip.com>
Update the SPI context during all transceive functions. This fixes a
deadlock where SPI transactions failed to give back the semaphore.
Verified on NPCX9 based Chromebook.
Signed-off-by: Keith Short <keithshort@google.com>
This adds an spi master mode driver via bitbanged gpio. Only syncronous
transfers are implemented. Clock signal timing is accomplished via busy
waits, the gpios are manipulated via the standard gpio interface; these
two factors limit the frequency at which it can operate - but here
a simple and generic implementation was chosen over performance.
The driver supports the various clock polarity and phase
configurations, and can also work with word sizes which are non
multiples of 8bits, currently up to 16 bits.
A sample program is also added demonstrating basic use of the driver
with 9bit data words.
Signed-off-by: Marc Reilly <marc@cpdesign.com.au>
Adds optional device tree properties to insert delays between spi chip
select assert/deassert and the clock edges, and also between spi
frames and transfers to the mcux flexcomm spi driver. If the properties
are not set, no additional delay is inserted.
Verified expected behavior on mimxrt685_evk and check with a scope
that the pre- and post-delay could be changed from the device tree
properties.
Signed-off-by: Bryce Wilkins <bryce.wilkins@gmail.com>
Adds DMA support to NXP's LPSPI driver. This can be enabled by selecting
the KConfig symbol CONFIG_SPI_MCUX_LPSPI_DMA, and requires the LPSPI
instances enabled in the devicetree to have valid DMA instances
assigned.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Without this change, when DTS SPI device node has node ID = <0>, the
value of 0 is assigned during SPI configuration and written to
whichPcs member in master_config structure.
This value wrongly overrides the default value read from NXP's DSPI
HAL (kDSPI_Pcs0 = 1U << 0).
Such situation occurs on ip_k66f board, where the DSA device -
controlled via SPI has the node ID equal to 0 (i.e. reg = <0>).
Signed-off-by: Lukasz Majewski <lukma@denx.de>
The device PM subsystem _depends_ on device, not vice-versa. Devices
only hold a reference to struct pm_device now, and initialize this
reference with the value provided in Z_DEVICE_DEFINE. This requirement
can be solved with a forward struct declaration, meaning there is no
need to include device PM headers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
commit 54907c7014
("drivers: spi: spi_context: improve support of multiple cs gpios")
added function to initialize all CS GPIOs defined in devicetree.
This function, spi_context_cs_configure_all, is intended to be
called during SPI driver initialization (POST_KERNEL init level).
It is also obvious that a SPI driver was not used at that time,
and no bus configuration (struct spi_config) is assigned to
SPI bus (spi_context.config).
The spi_context_cs_configure_all function has a homeopathic
ASSERT to validate CS levels, which causes a null pointer
dereferencing by ctx->config->operation if asserts are
enabled.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
This is meant to expose half/full duplex configuration option on regular
configuration. So far, dual/quad/octal are not exactly supported, as it
would require extensions to the SPI buffer for a full support.
So moving these modes to an extended operation attribute
(32 vs 16 bits), disabled by default.
And exposing half/full duplex configuration bit. Full duplex being the
default option.
Fixes#19134
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Port some drivers to the recently introduced macros to showcase its
usage and be able to do some initial testing (nRF52840).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In some cases, it is quite useful to have the possibility to also
include zero-length buffers in a buffer set used in transfers
(for example, when frames in a protocol consist of several parts,
of which some are optional). So far, the behavior of spi_context
update functions was that the transfer in a given direction was
finished when a zero-length buffer was encountered in the buffer
set. Change those functions to simply skip such buffers. Correct
in the same way also the spi_context_buffers_setup() function.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Do not use any timeout in the slave mode, as in this case it is not
known when the transfer will actually start and what the frequency
will be.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This is a follow-up to commits 99daca9bba
and ae03c0a6bf.
nRF SPI driver shims cannot use devicetree instance indexes, they need
to use the DT_NODELABEL macro and SoC peripheral instance indexes.
Correct the macros used in initialization of CS GPIOs in those shims.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Since cs gpios are initialized during driver initialization
remove spi_context_cs_configure that is not longer need.
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>