drivers: spi: stm32: allow for using soft NSS in peripheral mode #98446
Conversation
|
Hello @rob-zeno, and thank you very much for your first pull request to the Zephyr project! |
zephyrbot
added
platform: STM32
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
decsny,
djiatsaf-st,
erwango,
etienne-lms,
gautierg-st,
marwaiehm-st,
mathieuchopstm,
tbursztyka and
teburd
rob-zeno
force-pushed
the
feature/stm32_spi_softnss_peripheral
branch
2 times, most recently
from
09b46c8 to
700fb95
Compare
| type: boolean | ||
| description: Swap SPI MOSI and MISO pins | ||
|
|
||
| periph-use-soft-nss: |
There was a problem hiding this comment.
Maybe st,periph-soft-nss
The current stm32 drivers will only enable soft NSS support if the device is using a Zephyr managed GPIO for CS, or if the CONFIG_SPI_STM32_USE_HW_SS flag is set. Neither of these are actually appropriate for a peripheral, which doesn't control CS. With this change, it is possible for the SPI interface to be configured as a peripheral but still use soft NSS -- otherwise, short of creating a "fake" GPIO configuration, the peripheral will always use hard NSS, and for some boards/configurations, that is unworkable. In the case of a board where the CS is not hooked up, we can use soft NSS to allow the peripheral to assume CS and be driven by the SPI clock signal alone. Our board has only three signals (clock, COPI, POCI) enabled on one of the SPI interfaces (it is communicating with another MCU on the same board), and works with this change. Without the change, we must enable a "fake" GPIO driver configuration (which is never used for anything, and really makes little sense for a peripheral, but it just happens to force the driver to go down that code path). We cannot disable the CONFIG_SPI_STM32_USE_HW_SS mechanism, as that impacts ALL interfaces, and we have a second interface in controller mode that speaks to flash and requires the NSS_HARD codepath. Signed-off-by: Rob Newberry <rob@zenomoto.com>
rob-zeno
force-pushed
the
feature/stm32_spi_softnss_peripheral
branch
from
700fb95 to
7a31127
Compare
|
| (.midi_clocks = DT_INST_PROP(id, midi_clock),)) \ | ||
| IF_ENABLED(DT_HAS_COMPAT_STATUS_OKAY(st_stm32h7_spi), \ | ||
| (.mssi_clocks = DT_INST_PROP(id, mssi_clock),)) \ | ||
| .peripheral_use_soft_nss = DT_INST_PROP(id,periph_use_soft_nss) \ |
There was a problem hiding this comment.
As requested by CI + add trailing comma:
| .peripheral_use_soft_nss = DT_INST_PROP(id,periph_use_soft_nss) \ | |
| .peripheral_use_soft_nss = DT_INST_PROP(id, periph_use_soft_nss), \ |
There was a problem hiding this comment.
LGTM with @mathieuchopstm and CI comment addressed (and with a nitpicking comment).
|
|
||
| periph-use-soft-nss: | ||
| type: boolean | ||
| description: use soft NSS for this interface when in peripheral mode |
There was a problem hiding this comment.
Nitpicking:
| description: use soft NSS for this interface when in peripheral mode | |
| description: Use soft NSS for this interface when in peripheral mode |
5 participants
The current stm32 drivers will only enable soft NSS support if the device is using a Zephyr managed GPIO for CS, or if the CONFIG_SPI_STM32_USE_HW_SS flag is set. Neither of these are actually appropriate for a peripheral, which doesn't control CS.
With this change, it is possible for the SPI interface to be configured as a peripheral but still use soft NSS -- otherwise, short of creating a "fake" GPIO configuration, the peripheral will always use hard NSS, and for some boards/configurations, that is unworkable. In the case of a board where the CS is not hooked up, we can use soft NSS to allow the peripheral to assume CS and be driven by the SPI clock signal alone.
Our board has only three signals (clock, COPI, POCI) enabled on one of the SPI interfaces (it is communicating with another MCU on the same board), and works with this change. Without the change, we must enable a "fake" GPIO driver configuration (which is never used for anything, and really makes little sense for a peripheral, but it just happens to force the driver to go down that code path). We cannot disable the CONFIG_SPI_STM32_USE_HW_SS mechanism, as that impacts ALL interfaces, and we have a second interface in controller mode that speaks to flash and requires the NSS_HARD codepath.