nRF70: smarter SPI/QSPI interface control

[JordanYates]

Is your enhancement proposal related to a problem? Please describe.

Wi-Fi data throughput on the nRF70 Wi-Fi co-processors is primarily (based on my testing) influenced by two parameters:

1. CPU frequency (and the related option, CONFIG_SPEED_OPTIMIZATIONS)
2. SPI/QSPI bus speed

Neither of these are surprising:

1. The faster the CPU is, the faster it can handle the end of one transfer and start the next.
2. The faster the bus speed, the less time transfers take

Related to both of these parameters is the interface control of the bus, i.e. when to power it up or down.

For QSPI, the choice is driven by CONFIG_NRF70_QSPI_LOW_POWER:

• If the option is enabled, the QSPI bus is powered up and down on every bus transaction.
• If the option is disabled, the QSPI bus is powered up and down with the global interface.

For SPI, the choice is driven by whether PM is enabled on the bus or not (zephyr,pm-device-runtime-auto, etc):

• If PM is enabled, the SPI bus is powered up and down on every bus transaction.
• If PM is disabled, the SPI bus is powered up once at boot and left on

While these option work, they are quite coarse grained, leaving plenty of space for getting better performance than the first option for each case, while using less power than the second option.

Describe the solution you'd like

Firstly, an equivalent option to CONFIG_NRF70_QSPI_LOW_POWER for SPI, that allows PM to be enabled on the SPI bus, but brought up and down with the network interface, rather than once at boot or on every single bus transaction.

Secondly, it seems likely to me that each "interaction" with the nRF70 hardware would consist of multiple register/block reads/writes. Rather than toggling the power for each part of the interaction, I suspect it would be more efficient to power up the bus once at the start of some larger piece of logic that wants to use the bus, followed by power down at the end of that logic piece.

Looking at functions like rpu_mem_write_core, rpu_mem_write_bev, hal_rpu_event_get, etc.

Describe alternatives you've considered

Leaving the driver as is.

** Additional context **

I am not a developer of the driver and I don't know specifically what the critical path of function calls is for determining Wi-Fi throughput for an application like samples/net/zperf, and there may certainly be better places than I have suggested to do higher-level bus control.