RFC: Allow multiple ICE40 on the same SPI bus

[benediktibk]

Introduction

Currently it is not possible to have multiple ICE40 on the same SPI bus, as described in #77983. The reason for this is the necessity in some cases to do some bitbanging instead of real SPI to get the timing right. To do so the ICE40 driver currently instantiates the pinctrl config from its parent, the SPI master, which will create a name collision if multiple ICE40 are on the same SPI bus.

Proposed change

There are several options how this problem can be addressed:

1. Extend the SPI driver API with a function which resets or reapplies the pinctrl config. This was already proposed in Enable multiple ICE40 on the same bus #77980 and rejected by the SPI maintainer.
2. Implement a Kconfig which selects the available load modes (SPI and GPIO bitbang). This will then reduce the impact of the issue, as MCUs on which the GPIO bitbang mode is not required can then use multiple ICE40 on the same bus. But it won't solve it completely. - obsolete due to the merge of optional load modes for iCE40 #80854
3. Implement some peripheral deallocation/allocation mechanism, like in Support peripheral deallocation at runtime #20012. This would definitely resolve the issue, but it hasn't gotten much traction since its creation in 2019.
4. Modify the pinctrl macros to avoid the name collision. This would resolve the issue, but the pinctrl maintainer hasn't been too fond of the general idea that a foreign device modifies the pinctrl anyway.

This issue has already been discussed in the Dev-WG and the decision there was to try find a bigger audience to get more inputs. Therefore, I'm absolutely glad for ideas on how I can proceed. It is a nasty bug, which we should definitely get rid of in the long run.

[cfriedt]

This is a tricky one.

Next week is the riscv summit so I likely won't be able to make the arch meeting.

Is there any more information on option 3?

It would be great to have a good solution to the multi-instance problem.

[benediktibk]

This is a tricky one.

Next week is the riscv summit so I likely won't be able to make the arch meeting.

Is there any more information on option 3?

It would be great to have a good solution to the multi-instance problem.

No hurry from side, I can also try to get it into the Arch WG meeting on a later date.

Regarding option 3: My idea for this would be that the FPGA driver deinitializes its SPI master peripheral before the start of the bitbang operation and initializes it again afterwards. But as this infrastructure doesn't yet exist I do not have a more detailed plan than this.

[benediktibk]

The issue has been reduced in its effect with the merge into main of #80854, but it still exists.

[benediktibk]

Result from the Architecture WG today (I assume @carlescufi will correct me if I am mistaken):

The favoured approach is the one with the peripheral deallaction/reinit/PM-usage. Currently there is work going on by @fabiobaltieri and @gmarull to solve this general issue. As there is no hurry from my side or the maintainer (@cfriedt) we agreed upon waiting for this to land.

[carlescufi]

Result from the Architecture WG today (I assume @carlescufi will correct me if I am mistaken):

This is correct, thank you @benediktibk.