search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.96k stars 6.68k forks source link

RFC: Allow multiple ICE40 on the same SPI bus #80010

Open benediktibk opened 1 month ago

benediktibk commented 1 month ago

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 https://github.com/zephyrproject-rtos/zephyr/pull/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.
  3. Implement some peripheral deallocation/allocation mechanism, like in #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 commented 1 month ago

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 commented 1 month ago

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.