drivers: mspi: Support MSPI driver for STM32.

[ExaltZephyr]

This PR introduces support for MSPI driver on STM32, enabling functionality APIs for MSPI host controllers.

1. mspi_stm32_xspi driver

   • support xspi
   • tested using stm32h573i_dk and stm32h7s78_dk boards
   • functionalities:
     • Indirect Mode (read, write and erase).
     • DTR support.
     • Memory map mode (read and write).
     • xip configuration.
     • DMA Mode
     • Zephyr Power Management Support

2. ospi_stm32 driver

   • support octospi
   • tested using stm32h735g_disco and b_u585i_iot02a
   • functionalities:
     • Indirect mode (read, write and erase)
     • DTR support
     • Memory map mode
     • xip configuration
     • DMA transfer (b_u585i_iot02a board only, hdma isn't supported yet in zephyr)
     • zephyr power management support

3. mspi_stm32_qspi driver

   • support quadspi
   • tested using arduino_giga_r1/stm32h747xx/m7 and stm32l496g_disco
   • functionalities:
     • Indirect mode (read, write and erase) with MSPI_IO_MODE_SINGLE, MSPI_IO_MODE_QUAD_1_1_4, and MSPI_IO_MODE_QUAD_1_4_4
     • Memory map mode (read)
     • xip configuration
     • DMA transfer (stm32l496g_disco)
     • Zephyr Power Management Support

Notes:

• This PR was tested with JEDEC flash drivers and has not been tested with PSRAM.
• mspi_stm32_xspi driver - DMA mode here was tested using stm32h573i_dk board only since no zephyr dma support on stm32h7s78_dk

[erwango]

For the three IPs, these bindings will have to propose the same configuration options as the union of dts/bindings/memory-controllers/st,stm32-xspi-psram.yaml and dts/bindings/flash_controller/st,stm32-xspi-nor.yaml

[erwango]

Note that this may potentially be done as a follow up PR

[FRASTM]

@erwango Just to clarify one point: DMA support in our MSPI driver is working correctly — there’s no issue on our side.
The concern raised was about the hard-coded logic in the JEDEC flash driver (flash_mspi_nor.c), which always sends PIO requests and doesn’t include DMA handling. so @swift-tk's suggestion was to improve the JEDEC flash driver, not our MSPI driver.

Yes.

As far as I know, our DMA support is fine, @swift-tk correct ?

The only issue I see is that you should be checking xfer->xfer_mode == MSPI_DMA and place dma transceive calls after the check instead of using DMA all the time when CONFIG_MSPI_DMA is enabled. That's also what I meant by falling back to PIO if you need DMA to be off sometimes.

yes but first we need to improve flash jedec driver code then we can add this check "xfer->xfer_mode == MSPI_DMA" instead of kconfig checking

If you agree @swift-tk , we could raise a new issue for that improvement in the jedec driver

[etienne-lms]

Minor comments. Otherwise LGTM.

[etienne-lms]

Some CI compliance checks reports to be addressed:

 LONG_LINE: line length of 102 exceeds 100 columns
File:drivers/mspi/mspi_stm32_ospi.c
Line:1306
 LONG_LINE: line length of 102 exceeds 100 columns
File:drivers/mspi/mspi_stm32_xspi.c
Line:868
 LONG_LINE: line length of 102 exceeds 100 columns
File:drivers/mspi/mspi_stm32_xspi.c
Line:1392
Compliance error, check for error messages in the "Run Compliance Tests" step
You can run this step locally with the ./scripts/ci/check_compliance.py script.

[swift-tk]

My primary concern with this PR is the handling of flash-specific command transfers in the controller driver instead of the flash driver, which goes against the intended MSPI API design. ee https://github.com/zephyrproject-rtos/zephyr/pull/96670/files#r2575480446
That said, if there is agreement to move this logic out of the controller, I am okay with merging this PR as an intermediate step.

[swift-tk]

I'm guessing you use hardware CE only and support only one device under the same controller? There is no ce-gpios in DTS and yet mspi_verify_device is copied directly from ambiq driver.. What is the plan for multi-peripheral support?

@swift-tk Yes, that’s correct — currently, we only support one device connected to the controller. I don’t think there’s a plan to extend this for now. Should we remove mspi_verify_device then?

Sorry, I missed this from before. If there is no plan to support software multi-peripheral with GPIO or HW CE, then you can remove this code that would never be used.

[ExaltZephyr]

For users who want to run samples/sysbuild/with_mcuboot, please note that support for the XSPI/QSPI/OSPI controller must be added in flash_map_extended located at: bootloader/mcuboot/boot/zephyr/flash_map_extended.c

[ExaltZephyr]

Hi all,
any more comments on this PR?

[erwango]

Late request:
As there is an agreement later changes will be required, and driver is not yet ready for production. Let's make it explicit that is is still in experimental phase. This will give us more freedom in next steps.

[erwango]

Suggested change

	default y
	select EXPERIMENTAL
	default y

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
4.0% Duplication on New Code

See analysis details on SonarQube Cloud

[erwango]

Late catch. Probably wrong or to be put in readable format.

[ExaltZephyr]

I did not get this comment, could you please clarify what do you mean by ‘readable format’?

[erwango]

Clock freq set as follows feels quite odd:

 			clock-frequency = <0x17d7840>;

[erwango]

Late catch: Why is that requested while mspi-max-frequency prop is available ?

[ExaltZephyr]

yes, mspi-max-frequency should be enough but since this is an optional property, we need to assign a default value. We noticed that the maximum frequency varies across series, which is why we added this Kconfig. If you have any concerns, we can remove it and make mspi-max-frequency a required property instead

[erwango]

and make mspi-max-frequency a required property instead

That would be more simple indeed.

[ExaltZephyr]

sure, should we open a new PR now since this one is already merged?

[erwango]

Yes, please.

[swift-tk]

mspi-max-frequency is defined in mspi-device.yaml and is intended to describe the target operating frequency requested by the device. The clock-frequency in mspi-controller.yaml represents the maximum clock rate supported or configured for a given controller instance. These properties were inherited from the SPI bindings; however, the naming is arguably inverted. A more intuitive convention would be to use clock frequency on the device side and maximum frequency on the controller side...

[ExaltZephyr]

@swift-tk regarding last sentence, u meant to use clock_frequency on controller side not device side, right? since we have clock-frequency property in mspi-controller.yaml ?

[swift-tk]

I meant their names are inverted in my opinion. But currently, clock-frequency is on controller side and mspi-max-frequency on device side. Note that mspi-max-frequency should not be used as maximum frequency indication for the controller!!

[ExaltZephyr]

ok got it, thanks

[ExaltZephyr]

@erwango @swift-tk I have opened new PR for this refactor: #101935