| Message ID | 20250606-cs_change_fix-v1-0-27191a98a2e5@non.se.com |
|---|---|
| Headers | show |
| Series | SPI: omap2-mcspi: Fix SPI CS behaviour around cs_change in SPI transfers | expand |
On Fri, 06 Jun 2025 15:37:23 +0200, Félix Piédallu wrote: > These patches fix the behaviour of the SPI Chip Select of the OMAP2 MCSPI > driver used on TI SoCs. > > The omap2-mcspi driver supports the use of multi mode (multichannel in TI > documentation). In this mode, the CS is asserted and deasserted by the > hardware. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/2] spi: omap2-mcspi: Disable multi mode when CS should be kept asserted after message commit: a5bf5272295d3f058adeee025d2a0b6625f8ba7b [2/2] spi: omap2-mcspi: Disable multi-mode when the previous message kept CS asserted commit: 10c24e0d2f7cd2bc8a847cf750f01301ce67dbc8 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
These patches fix the behaviour of the SPI Chip Select of the OMAP2 MCSPI driver used on TI SoCs. The omap2-mcspi driver supports the use of multi mode (multichannel in TI documentation). In this mode, the CS is asserted and deasserted by the hardware. The multi mode is disabled for messages when cs_change=0 for all transfers (e.g when CS is kept asserted between transfers of a same message). The multi mode also needs to be disabled for messages when cs_change=1 on the last transfer (e.g when CS is kept asserted after the WHOLE message), and the message right after. Currently, that is not the case and it CS is deasserted by hardware when it shouldn't. This breaks peripheral drivers that send multiple messages with the CS asserted in between. Patch 1 ensures that multi mode is disabled when cs_change=1 on the last transfer of the message. Patch 2 ensures that multi mode is disable on a message following one with cs_change=1 on the last transfer. This is the case for the TPM TIS SPI driver that uses this logic for flow control purposes. Tested on an AM6442 platform with a TPM ST33HTPH2X32AHE4. Signed-off-by: Félix Piédallu <felix.piedallu@non.se.com> --- Félix Piédallu (2): spi: omap2-mcspi: Disable multi mode when CS should be kept asserted after message spi: omap2-mcspi: Disable multi-mode when the previous message kept CS asserted drivers/spi/spi-omap2-mcspi.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) --- base-commit: c46b66be7eb595e66e93eda13149e0d4f90924ea change-id: 20250606-cs_change_fix-bb51ac0f2bcb Best regards,