spi: add spi_acquire API

[JordanYates]

Add a counterpart to the spi_release function call that locks the context without needing to initiate a transaction. This is intended to be used when SPI bus access needs to be blocked before the device is accessed.

One example of this requirement is power cycling an SD card, where the bus should be kept idle after power up until starting the switch from SD mode to SPI mode. This requires locking the bus before power is applied.

Currently no tests in this PR, there doesn't appear to be any tests of spi_release in the tree, happy to take suggestions on what to do.

[decsny]

what is the use case of this? and I didn't understand why the SD card requires locking/acquiring the spi bus

note: the block is over the error codes documentation, I am fine with adding a "symmetrical" API to spi_release

[JordanYates]

what is the use case of this? and I didn't understand why the SD card requires locking/acquiring the spi bus

Because the SD card spec has a range of requirements around bus activity when powering up (see below). SPI bus activity to other devices on the bus during this time has a habit of breaking the initialization flow (Due to either activity on the MOSI line while CLK is toggling but CS is low, or any bus activity at all in the supply ramp up time). This is a problem seen on real cards.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
25.0% Duplication on New Code

See analysis details on SonarQube Cloud

[decsny]

what is the use case of this? and I didn't understand why the SD card requires locking/acquiring the spi bus

Because the SD card spec has a range of requirements around bus activity when powering up (see below). SPI bus activity to other devices on the bus during this time has a habit of breaking the initialization flow (Due to either activity on the MOSI line while CLK is toggling but CS is low, or any bus activity at all in the supply ramp up time). This is a problem seen on real cards.

You said "while CS is low" it causes a problem, and the datasheet you screenshotted says to keep it high for 74 cycles. Isn't then the solution just to keep the CS high? I still don't understand what is the need to lock all other spi device from using the bus, since they have separate CS

[tbursztyka]

I don't see a need for API change for such corner case.

A way to do what you want already I think, if you really need to lock a SPI controller to a user (whatever the reason is), will be to just have a temporary spi_config as a copy of your dts based spi_config but with SPI_LOCK_ON bit set, call spi_write with valid spi_buf_set but a spi_buf of length 0. It should be going through the config, setting the ownership and do nothing on the bus (at least not sending any data) and return now with the caller having the lock until calling spi_release with that same temporary config. No?

[tbursztyka]

see my previous comment

[JordanYates]

It should be going through the config, setting the ownership and do nothing on the bus (at least not sending any data) and return now with the caller having the lock until calling spi_release with that same temporary config. No?

Maybe in theory, but thats not the case even in the first controller I look at, spi_nrfx_spim.c. Even ignoring whatever transfer_next_chunk does if presented with a data length of 0, it will assert the CS line, which is exactly the opposite of what the SD card wants.

I agree that its a corner case, but supporting it this way is much lower overhead than looking at every driver and checking how it would have a transaction of length 0.

[JordanYates]

You said "while CS is low" it causes a problem, and the datasheet you screenshotted says to keep it high for 74 cycles. Isn't then the solution just to keep the CS high? I still don't understand what is the need to lock all other spi device from using the bus, since they have separate CS

Sorry, my comment had it around the wrong way. Yes the CS needs to be high for 74 cycles. The problem is that on actual cards, the MOSI line toggling even while the CS line is high is enough to cause problems, presumably because the card is not yet in SPI mode and the toggling is being treated as part of some SDIO transaction.

addressed