drivers: spi: stm32: fix hardware NSS management
The LL_SPI_NSS_* macros used in spi_stm32_configure() when
hardware-based NSS management is requested are incorrect; fix them.
In master mode, this seems like a copy/paste error. The slave mode
case is likely due to following incorrect documentation in the ST LL
headers.
Note that in my testing on STM32F4, NSS appears to be open drain when
managed by hardware, making that configuration harder to test (and
probably less useful).
Details for the curious:
The ST LL headers (for example stm32f4xx_ll_spi.h) claim
LL_SPI_NSS_HARD_INPUT is to be used only in master mode, and
LL_SPI_NSS_HARD_OUTPUT is to be used in slave mode.
The opposite is true: when NSS is not handled by software, the SPI
peripheral is responsible for driving NSS as an output, and the
slave peripheral is responsible for reading it as an input.
This is an error in the LL header files; the reference manuals and
the other LL code make this clear.
- The ST reference manuals specify that LL_SPI_HARD_OUTPUT (which
corresponds to SSM unset, SSOE set) is a master-only
configuration. For example, STM32 RM0368 says:
"NSS output enabled (SSM = 0, SSOE = 1)
This configuration is used only when the device operates in
master mode."
- LL_SPI_HARD_INPUT (SSM unset, SSOE unset) is either a master or
a slave configuration; in the slave case (which is what we're
interested in here), it corresponds to the "usual" NSS
input. RM0368, again:
"NSS output disabled (SSM = 0, SSOE = 0)
This configuration allows multimaster capability for devices
operating in master mode. For devices set as slave, the NSS
pin acts as a classical NSS input: the slave is selected when
NSS is low and deselected when NSS high."
The LL_SPI_StructInit() implementations similarly combine
LL_SPI_MODE_SLAVE with LL_SPI_NSS_HARD_INPUT.
Signed-off-by:
Marti Bolivar <marti.bolivar@linaro.org>
Loading
Please sign in to comment