SPI Chip Select usage is not unambiguous

[vlotech]

In the different SPI drivers for each of the SoC's i noticed that there's no control mentioned over the peripheral own chip select line(s). Only in case a GPIO is used, the behavior is defined.
Some chipset have multiple CS lines per peripheral. There is no interface given to map devices to each of the chipsets.

secondly, the flag SPI_HOLD_ON_CS is only used for the gpio version in all drivers, but the CS is never cleared in the release call, so at least a transfer is needed to clear the chip-select. This could be problemantic.
E.g. In case the output of the first transaction tells the higher level driver, there's no use to continue to communicate, there's no means to set the chip-select inactive without doing another SPI transfer.
(Most drivers simply skip the chip select and configuration step when the config pointer didn't change and/or there are no buffers supplied.

[tbursztyka]

Ok, I'll check this seems-to-be-a-bug spi_release().

About hw CS line controls, the use-case never popped up so far. Thus why, currently, it affects the gpio emulated CS lines. However, through the same struct spi_cs_control you could affect the controller CS lines: gpio-dev could be NULL, gpio-pin set to UINT_MAX (or we don't care about its value, either way) and delay would be a valid value in µs. Up then to the driver to handle that case properly. Of course, API description would need an update.

There is no need of any other interface: you know which hw CS line you are using via the slave attribute in spi_config. And that does reflects the actual hw wiring.

Mapping of slave numbering to actual peripheral in each and every spi_config should done at built time, via DTS (well, unless some are still using Kconfig for that) and again that must reflect the actual hw wiring.

[tbursztyka]

@vlotech Can you have a look at the linked PR?

[vlotech]

Looks like the mentioned PR will solve the SPI CS lock issue as mentioned in this issue.
Looking at the different SPI drivers, there seems to be an inconsistent usage between _release and _inactive_unconditionally(). Perhaps at a later stage this an be aligned. For now, this prevents at least unexpected CS to be active after transactions / communication.

[vlotech]

For the hardware CS, I'll take a look at it for the SAM4S and similar driver to see what the impact will be to include hardware CS.