drivers: mspi: Add driver for Designware SSI based controllers

[anangl]

Add a generic driver for MSPI controllers based on the DesignWare SSI core. With small vendor-specific adaptations covering integration details, it should be possible to use the driver for various devices.

[anangl]

Rebased.

[swift-tk]

I think we should return the pm_device_*(dev_config->bus) calls to the controller as it seems to be leaking. For other stuff in the flash device driver, it can be further refined in following PRs.

[swift-tk]

I don't suppose you can open/close a certain device in different context, as they are blocked by acquire below

zephyr/drivers/flash/flash_mspi_nor.c

Line 57 in 4f892e9

k_sem_take(&dev_data->acquired, K_FOREVER);

In contrast, you can open/close different device in different context, but these device may share the same controller. That's why it should be a mutex(Ln675) which is capable of inheriting priority. This sem here is then redundent as mspi API calls from flash device driver layer are encapsulated between mspi_dev_config and mspi_get_channel_status and then again encapsulated between acquire and release.
So what is the reason for not following this with other drivers?

[swift-tk]

@anangl resolved or not?

[swift-tk]

okay, there is only two other places that needs change/clarify

[anangl]

I think we should return the pm_device_*(dev_config->bus) calls to the controller as it seems to be leaking. For other stuff in the flash device driver, it can be further refined in following PRs.

The controller driver (mspi_dw.c) makes the pm_device_runtime_*() calls for itself (get right before a transfer and put after it is finished), just in case its user would not do it. But having these calls also in the flash driver has the advantage that the controller will not be unnecessarily suspended between transfers if an operation consists of several (a write operation requires executing WREN and then the actual write, an erase operation may involve erasing of multiple sectors for example). You can see that the spi_nor driver uses the same approach:

zephyr/drivers/flash/spi_nor.c

Line 587 in c0f76d9

(void)pm_device_runtime_get(cfg->spi.bus);

I refactored a bit the logic in acquire() because in its previous shape the acquired semaphore would incorrectly remain taken when the function was unsuccessful due to failed pm_device_runtime_get() or mspi_dev_config(). But I kept the pm_device_runtime_get(dev_config->bus) call there for the reason I explained above.

[swift-tk]

The controller driver (mspi_dw.c) makes the pm_device_runtime_*() calls for itself

This is exactly why I think the control of the controller state is leaking into flash driver, because there will be different implementation of the controller and logics as to where to put the pm_device_runtime_*() calls. This in result will potentially create asymmetry calls of put and get and then result in incorrect state of the controller.

[swift-tk]

The updated code does not conflict with the upcoming PM_RUNTIME support in Ambiq controllers but it would prematurly wake up the controller, so I would not block the PR. However, I still insist that the PM managment should be left within each device itself and not leaking into other devices whatever the hierarchy relationship between them.

[anangl]

The controller driver (mspi_dw.c) makes the pm_device_runtime_*() calls for itself

This is exactly why I think the control of the controller state is leaking into flash driver, because there will be different implementation of the controller and logics as to where to put the pm_device_runtime_*() calls. This in result will potentially create asymmetry calls of put and get and then result in incorrect state of the controller.

The runtime PM resumes and suspends devices based on their usage count - the device stays resumed as long as there was more get() than put() calls executed, so it is not a problem at all that the calls are done on multiple layers. Just every layer needs to take care of doing as many put() calls as it did the get() ones and I'm doing it in these drivers here. So I don't quite understand what you actually see as potentially problematic.

[swift-tk]

The runtime PM resumes and suspends devices based on their usage count - the device stays resumed as long as there was more get() than put() calls executed, so it is not a problem at all that the calls are done on multiple layers. Just every layer needs to take care of doing as many put() calls as it did the get() ones and I'm doing it in these drivers here. So I don't quite understand what you actually see as potentially problematic.

I'm only putting one get() in mspi_dev_config() and one put() in mspi_get_channel_status in no error conditions as turning our controller on and off in different places is needless and may be more time and power consuming. In fact, it is already slower by doing so because of the frequent acquire and release in flash drivers. It is just going to be even slower with all these needless counting in flash drivers. So basically I'm just allowing the usage count to be 0 or 1 to save more CPU cycles.