spi: SPI_LOCK_ON does not hold the lock for multiple spi_transceive until spi_release

[bigstefan]

Problem
On our custom HW we have two spi devices on the same spi bus.
One device is a TPM2 with special requirements concerning holding the CS active during multiple spi_transceive.
Setting the SPI_HOLD_ON_CS works fine, it holds the CS active until spi_release.
But the second device access the bus in before the transfer is completed (with spi_release).
Both CS are active at the same time and the access fails.
We are using the synchronous API. Both devices are served from different threads.

To Reproduce
Run 2 threads

• access the TPM2

  spi_setup SPI_HOLD_ON_CS, SPI_LOCK_ON
  spi_transceive
  spi_transceive
  spi_release
  

• access the second device

  spi_setup ! SPI_HOLD_ON_CS, ! SPI_LOCK_ON
  spi_transceive
  

Expected behavior
I expect that for the TPM2 the spi bus lock is kept from the first spi_transceive until the spi_release.
For the Switch device the lock is only kept within the spi_transceive. For the same time that also the CS is kept active.

Do I have the correct understanding of the expected behavior defined in the documentation?
https://docs.zephyrproject.org/2.4.0/reference/peripherals/spi.html?highlight=spi#c.spi_release

Environment:

• Zephyr 2.4.0
• zephyr-sdk-0.11.3
• CPU MK64FN1M0XXX12 (board based on FRDM_K64F)

Code
In the code spi_context.h
https://github.com/zephyrproject-rtos/zephyr/blob/zephyr-v2.4.0/drivers/spi/spi_context.h#L95
we can see that the lock is given back unconditionally on the SPI_LOCK_ON for the synchronous API.

[bigstefan]

There are 2 possiblites to fix the problem:

1. Add an explicit call to take the lock (breaks the API)
2. Add a mechanism to save the owner device that took the lock

For the second option I did a implementation #29320 and tested it on my tartget (FRDM_K64F)
The code must be enhanced for all SPI device, as soon the concept is accepted

[nashif]

@tbursztyka can you look at that?

[drandreas]

I think this was fixed with #29320

[bigstefan]

Yes it is fixed with #29320