drivers: mspi: Support MSPI driver for STM32. #96670

ExaltZephyr · 2025-09-28T09:17:48Z

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

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
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 (read b_u585i_iot02a board)
  - xip configuration
  - DMA transfer (b_u585i_iot02a board)
  - zephyr power management support
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 · 2025-10-02T15:37:39Z

dts/bindings/mspi/st,stm32-xspi-controller.yaml

Please rename to dts/bindings/mspi/st,stm32-xspi-controller.yaml MSPI is the subsytem api and XSPI is the ST IP name.
Apply everywhere (driver files, ....) on this PR..

dts/bindings/mspi/st,stm32-mspi-controller.yaml

drivers/mspi/CMakeLists.txt

drivers/mspi/mspi_stm32.c

erwango · 2025-10-02T16:01:01Z

dts/bindings/mspi/st,stm32-xspi-controller.yaml

+      For example
+         dma-names = "tx_rx";
+
+  ssht-enable:


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

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

erwango · 2025-11-18T15:02:02Z

dts/bindings/mspi/st,stm32-xspi-controller.yaml

+    Enabling a stm32 xspi node in a board
+    description would typically requires this: (pinning depends on the stm32 mcu)
+
+        &xspi {
+            pinctrl-0 = <&octospi_clk_pe9 &octospi_ncs_pe10 &octospi_dqs_pe11
+                         &octospi_io0_pe12 &octospi_io1_pe13
+                         &octospi_io2_pe14 &octospi_io3_pe15
+                         &octospi_io4_pe16 &octospi_io5_pe17
+                         &octospi_io6_pe18 &octospi_io7_pe19>;
+
+            pinctrl-names = "default";
+
+            status = "okay";
+        };


This is not fully correct as you omit the dtsi part of the node. Pinning doesn't depends on the mcu, but depends on the board, ....
I would fully remove this part to avoid discussions on that part which will be long to get agreed by everyone.

erwango · 2025-11-18T15:03:55Z

dts/bindings/mspi/st,stm32-xspi-controller.yaml

+  reg:
+    required: true
+
+  interrupts:
+    required: true
+
+  pinctrl-0:
+    required: true
+
+  pinctrl-names:
+    required: true
+
+  clocks:
+    required: true
+
+  clock-names:
+    required: true


Most of those are already part of the includes above. Please clean up.

@erwango
yes correct but here I just marked them as required since in include files they are not marked as required
what do you think ?

erwango · 2025-11-18T15:06:03Z

drivers/mspi/Kconfig.stm32

+# Copyright (c) 2025 STMicroelectronics
+# SPDX-License-Identifier: Apache-2.0
+
+config MSPI_STM32_XSPI


Please sort alphabetically whenvener it is possible.

erwango · 2025-11-18T15:07:46Z

drivers/mspi/mspi_stm32.h

+#ifdef CONFIG_MSPI_STM32_XSPI
+	XSPI_HandleTypeDef xspi;
+#endif
+#ifdef CONFIG_MSPI_STM32_OSPI
+	OSPI_HandleTypeDef ospi;
+#endif
+#ifdef CONFIG_MSPI_STM32_QSPI
+	QSPI_HandleTypeDef qspi;


Ditto on alphabetical sorting

erwango · 2025-11-18T15:08:40Z

drivers/mspi/mspi_stm32_common.c

+#ifndef LL_DMA_SRC_DATAWIDTH_BYTE
+#define LL_DMA_SRC_DATAWIDTH_BYTE    LL_DMA_MDATAALIGN_BYTE
+#endif
+
+#ifndef LL_DMA_SRC_DATAWIDTH_HALFWORD
+#define LL_DMA_SRC_DATAWIDTH_HALFWORD    LL_DMA_MDATAALIGN_HALFWORD
+#endif
+
+#ifndef LL_DMA_SRC_DATAWIDTH_WORD
+#define LL_DMA_SRC_DATAWIDTH_WORD    LL_DMA_MDATAALIGN_WORD
+#endif
+
+#ifndef LL_DMA_DEST_DATAWIDTH_BYTE
+#define LL_DMA_DEST_DATAWIDTH_BYTE    LL_DMA_PDATAALIGN_BYTE
+#endif
+
+#ifndef LL_DMA_DEST_DATAWIDTH_HALFWORD
+#define LL_DMA_DEST_DATAWIDTH_HALFWORD    LL_DMA_PDATAALIGN_HALFWORD
+#endif
+
+#ifndef LL_DMA_DEST_DATAWIDTH_WORD
+#define LL_DMA_DEST_DATAWIDTH_WORD    LL_DMA_PDATAALIGN_WORD
+#endif


Please avoid redefining LL symbols, but use new symbols instead.

erwango · 2025-11-18T15:11:21Z

drivers/mspi/mspi_stm32_common.c

Is this file really useful vs already available mspi_stm32.h ?

Ys, it's needed to define global arrays mspi_stm32_table_...[].

erwango · 2025-11-18T15:15:01Z

drivers/mspi/mspi_stm32_ospi.c

+		return ret;
+	}
+
+	if (IS_ENABLED(MSPI_STM32_DOMAIN_CLOCK_SUPPORT) && (config->pclk_len > 1)) {


Let's remove use of MSPI_STM32_DOMAIN_CLOCK_SUPPORT in the driver. It's bringing confusion and saving implied is neglectible vs the size of the driver.

etienne-lms · 2025-11-18T15:12:13Z

include/zephyr/drivers/spi/spi_nor.h

+ */
+
+#ifndef __SPI_NOR_H__
+#define __SPI_NOR_H__


#ifndef ZEPHYR_INCLUDE_DRIVERS_SPI_SPI_NOR_H_ #define ZEPHYR_INCLUDE_DRIVERS_SPI_SPI_NOR_H_

etienne-lms · 2025-11-18T15:15:00Z

include/zephyr/drivers/spi/spi_nor.h

+#define SPI_NOR_IS_32K_ALIGNED(_ofs) SPI_NOR_IS_ALIGNED(_ofs, 15)
+#define SPI_NOR_IS_64K_ALIGNED(_ofs) SPI_NOR_IS_ALIGNED(_ofs, 16)
+
+#define CMD_RDCR 0x15 /* Read the configuration register. */


For consistency, this macro should be renamed SPI_NOR_CMD_RDCR.

For that purpose, I think you can squash commits "include: spi: Move spi_nor.h to include folder"
and "drivers: flash: Adjust include paths for spi_nor.h".

etienne-lms · 2025-11-18T15:27:28Z

drivers/mspi/mspi_stm32_common.c

Ys, it's needed to define global arrays mspi_stm32_table_...[].

etienne-lms · 2025-11-18T15:34:16Z

drivers/mspi/mspi_stm32_ospi.c

+		return ret;
+	}
+
+	OSPI_RegularCmdTypeDef s_command = mspi_stm32_ospi_prepare_cmd(cfg_mode, cfg_rate);


Could you add an empty line below this local variable definition?

etienne-lms · 2025-11-18T15:44:31Z

drivers/mspi/mspi_stm32_qspi.c

+
+	/* For ASYNC mode, wait for IRQ completion (PM locks released in ISR) */
+	if (k_sem_take(&dev_data->sync, K_FOREVER) < 0) {
+		LOG_ERR("Failed to complete async transfer");


pm_policy_state_lock_put(PM_STATE_SUSPEND_TO_IDLE, PM_ALL_SUBSTATES); (void)pm_device_runtime_put(dev);

etienne-lms · 2025-11-18T15:57:31Z

drivers/mspi/mspi_stm32_xspi.c

+
+	if (mspi_stm32_xspi_is_inp(controller)) {
+		ret = -EBUSY;
+		goto e_return;


Can put PM ressource at this stage (as done at e_return branch label).

etienne-lms · 2025-11-18T16:04:28Z

drivers/mspi/mspi_stm32_ospi.c

+	/* Lock with the expected timeout value = ctx->xfer.timeout */
+	ret = mspi_stm32_ospi_context_lock(ctx, dev_data->dev_id, xfer, true);
+	if (ret != 0) {
+		goto status_end;


Should not call k_sem_give(&ctx->lock) at function exit.

Suggestion:

static int mspi_stm32_ospi_status_reg(const struct device *controller, const struct mspi_xfer *xfer) { // here, return straight upon error (void)pm_device_runtime_get(controller); pm_policy_state_lock_get(PM_STATE_SUSPEND_TO_IDLE, PM_ALL_SUBSTATES); // here `goto pm_put` upon error ret = mspi_stm32_ospi_context_lock(ctx, dev_data->dev_id, xfer, true); // here `goto ctx_unlock` upon error ctx_unlock: k_sem_give(&ctx->lock); pm_put: pm_policy_state_lock_put(PM_STATE_SUSPEND_TO_IDLE, PM_ALL_SUBSTATES); (void)pm_device_runtime_put(controller); return ret; }

See also the QSPI and XSPI drivers for equivalent issues.

etienne-lms · 2025-11-18T16:07:44Z

drivers/mspi/mspi_stm32_ospi.c

+status_end:
+	pm_policy_state_lock_put(PM_STATE_SUSPEND_TO_IDLE, PM_ALL_SUBSTATES);
+	(void)pm_device_runtime_put(controller);
+	k_sem_give(&ctx->lock);


To here finding where context lock is locked/taken and unlocked/given, I think it would help to have a helper function that matches mspi_stm32_ospi_context_lock():

static inline void mspi_stm32_ospi_context_unlock(struct mspi_stm32_context *ctx) { k_sem_give(&ctx->lock); }

Ditto in QSPI and XSPI drivers.

drivers/mspi/mspi_stm32_xspi.c

This commit moves spi_nor.h from drivers/flash to include/drivers/spi directory and updates affected flash drivers with new include path Signed-off-by: Sara Touqan <[email protected]> Signed-off-by: Sarah Younis <[email protected]> Signed-off-by: Mohammad Odeh <[email protected]>

tpambor

We are looking to use this driver together with a PSRAM, which would require support for MSPI_DATA_RATE_S_D_D. Maybe you could also support these modes.

tpambor · 2025-11-19T10:29:06Z

drivers/mspi/mspi_stm32_xspi.c

+					     ? HAL_XSPI_INSTRUCTION_DTR_ENABLE
+					     : HAL_XSPI_INSTRUCTION_DTR_DISABLE;
+	cmd_tmp.AlternateBytesMode = HAL_XSPI_ALT_BYTES_NONE;
+	cmd_tmp.AddressDTRMode = (cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_ADDRESS_DTR_ENABLE


Suggested change

cmd_tmp.AddressDTRMode = (cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_ADDRESS_DTR_ENABLE

cmd_tmp.AddressDTRMode = ((cfg_rate == MSPI_DATA_RATE_DUAL) || (cfg_rate == MSPI_DATA_RATE_S_D_D)) ? HAL_XSPI_ADDRESS_DTR_ENABLE

tpambor · 2025-11-19T10:30:35Z

drivers/mspi/mspi_stm32_xspi.c

+								: HAL_XSPI_DATA_DTR_DISABLE;
+	/* AddressWidth must be set to 32bits for init and mem config phase */
+	cmd_tmp.AddressWidth = HAL_XSPI_ADDRESS_32_BITS;
+	cmd_tmp.DataDTRMode = (cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_DATA_DTR_ENABLE


Suggested change

cmd_tmp.DataDTRMode = (cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_DATA_DTR_ENABLE

cmd_tmp.DataDTRMode = (cfg_rate != MSPI_DATA_RATE_SINGLE) ? HAL_XSPI_DATA_DTR_ENABLE

tpambor · 2025-11-19T10:36:21Z

drivers/mspi/mspi_stm32_xspi.c

+	cmd_tmp.DataDTRMode = (cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_DATA_DTR_ENABLE
+								: HAL_XSPI_DATA_DTR_DISABLE;
+	cmd_tmp.DQSMode =
+		(cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_DQS_ENABLE : HAL_XSPI_DQS_DISABLE;


Suggested change

(cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_DQS_ENABLE : HAL_XSPI_DQS_DISABLE;

(cfg_rate != MSPI_DATA_RATE_SINGLE) ? HAL_XSPI_DQS_ENABLE : HAL_XSPI_DQS_DISABLE;

erwango · 2025-11-19T10:47:30Z

We are looking to use this driver together with a PSRAM, which would require support for MSPI_DATA_RATE_S_D_D. Maybe you could also support these modes.

This could also be added later. I prefer we get a more simple version soon, on which contributions could be made.

erwango · 2025-11-19T10:50:11Z

drivers/mspi/mspi_stm32.h

+/* Macro to check if any xspi device has a domain clock or more */
+#define MSPI_STM32_DOMAIN_CLOCK_INST_SUPPORT(inst) DT_CLOCKS_HAS_IDX(DT_INST_PARENT(inst), 1) ||
+#define MSPI_STM32_INST_DEV_DOMAIN_CLOCK_SUPPORT                                                   \
+	(DT_INST_FOREACH_STATUS_OKAY(MSPI_STM32_DOMAIN_CLOCK_INST_SUPPORT) 0)
+
+/* This symbol takes the value 1 if device instance has a domain clock in its dts */
+#if MSPI_STM32_INST_DEV_DOMAIN_CLOCK_SUPPORT
+#define MSPI_STM32_DOMAIN_CLOCK_SUPPORT 1
+#else
+#define MSPI_STM32_DOMAIN_CLOCK_SUPPORT 0
+#endif


Not required anymore (to be cleaned up from all O/Q/X drivers variants.

FRASTM

Maybe moving this spi_nor.h header file could have its own PR ?

ExaltZephyr · 2025-11-19T13:23:21Z

Maybe moving this spi_nor.h header file could have its own PR ?

@etienne-lms is it ok with you to revert the commit of moving spi_nor.h and then later another PR can be opened?

erwango · 2025-11-19T14:57:03Z

@etienne-lms is it ok with you to revert the commit of moving spi_nor.h and then later another PR can be opened?

I think that the point of @FRASTM was not to do it later, but before.
So request is to split it in another PR now and it will be merged before current PR.

etienne-lms · 2025-11-19T17:00:14Z

I think that the point of @FRASTM was not to do it later, but before.
So request is to split it in another PR now and it will be merged before current PR.

I agree. It would allow the SPI maintainer (@swift-tk) to explicitly agree (or not) on this change.
Unless @swift-tk you're ok with such a change and agree it's reviewed and merged as part of the MSPI P-R.

This commit adds the main DTS configurations required to enable MSPI/OSPI/QSPI support on STM32. Signed-off-by: Sara Touqan <[email protected]> Signed-off-by: Sarah Younis <[email protected]> Signed-off-by: Mohammad Odeh <[email protected]>

This commit introduces support for the mspi and ospi drivers on STM32, enabling functionality APIs for MSPI/OSPI/QSPI host controllers.. Signed-off-by: Sara Touqan <[email protected]> Signed-off-by: Sarah Younis <[email protected]> Signed-off-by: Mohammad Odeh <[email protected]>

ExaltZephyr · 2025-11-20T12:44:35Z

I think that the point of @FRASTM was not to do it later, but before.
So request is to split it in another PR now and it will be merged before current PR.

I agree. It would allow the SPI maintainer (@swift-tk) to explicitly agree (or not) on this change. Unless @swift-tk you're ok with such a change and agree it's reviewed and merged as part of the MSPI P-R.

ok then we can open new PR for this header change.
@swift-tk ok with you ?

this commit enables building and running the sample on stm32h573i_dk board,stm32h735g_disco board, arduino_giga_r1 board, and b_u585i_iot02a board by providing the required overlay and configuration updates. Signed-off-by: Sara Touqan <[email protected]> Signed-off-by: Sarah Younis <[email protected]> Signed-off-by: Mohammad Odeh <[email protected]>

ExaltZephyr · 2025-11-20T12:51:02Z

Updated PR description to add DMA support for QSPI driver. Tested on STM32L496G-DISCO.

sonarqubecloud · 2025-11-20T13:18:30Z

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

ExaltZephyr force-pushed the stm32-mspi-support branch 8 times, most recently from 834dc73 to 7e8241c Compare September 29, 2025 11:59

FRASTM mentioned this pull request Sep 30, 2025

[WIP] stm32 MSPI controller driver #93320

Closed

4 tasks

ExaltZephyr force-pushed the stm32-mspi-support branch 6 times, most recently from ed327ea to a09a921 Compare October 2, 2025 14:03

erwango reviewed Oct 2, 2025

View reviewed changes

dts/bindings/mspi/st,stm32-mspi-controller.yaml Outdated Show resolved Hide resolved

erwango reviewed Oct 2, 2025

View reviewed changes

drivers/mspi/CMakeLists.txt Outdated Show resolved Hide resolved

erwango reviewed Oct 2, 2025

View reviewed changes

drivers/mspi/mspi_stm32.c Outdated Show resolved Hide resolved

erwango reviewed Oct 2, 2025

View reviewed changes

ExaltZephyr force-pushed the stm32-mspi-support branch 9 times, most recently from e0849ca to 806f0f8 Compare October 6, 2025 12:23

erwango requested a review from Copilot October 6, 2025 12:25

zephyrbot requested review from MaureenHelm, manuargue and masz-nordic November 18, 2025 10:36

ExaltZephyr force-pushed the stm32-mspi-support branch 3 times, most recently from fc323fc to 6cf8d2c Compare November 18, 2025 13:35

erwango requested changes Nov 18, 2025

View reviewed changes

etienne-lms reviewed Nov 18, 2025

View reviewed changes

ExaltZephyr force-pushed the stm32-mspi-support branch from 6cf8d2c to 6a7d2c8 Compare November 19, 2025 08:10

zephyrbot requested a review from erwango November 19, 2025 08:12

ExaltZephyr force-pushed the stm32-mspi-support branch 2 times, most recently from a6d3767 to c1ceacb Compare November 19, 2025 10:03

ExaltZephyr force-pushed the stm32-mspi-support branch from c1ceacb to 7c1ab3e Compare November 19, 2025 10:07

tpambor reviewed Nov 19, 2025

View reviewed changes

erwango requested changes Nov 19, 2025

View reviewed changes

FRASTM reviewed Nov 19, 2025

View reviewed changes

ExaltZephyr added 2 commits November 20, 2025 14:21

ExaltZephyr force-pushed the stm32-mspi-support branch from 7c1ab3e to 897c655 Compare November 20, 2025 12:22

zephyrbot requested a review from erwango November 20, 2025 12:25

ExaltZephyr force-pushed the stm32-mspi-support branch from 897c655 to a7ad0cf Compare November 20, 2025 12:50

	cmd_tmp.AddressDTRMode = (cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_ADDRESS_DTR_ENABLE
	cmd_tmp.AddressDTRMode = ((cfg_rate == MSPI_DATA_RATE_DUAL) \|\| (cfg_rate == MSPI_DATA_RATE_S_D_D)) ? HAL_XSPI_ADDRESS_DTR_ENABLE

	cmd_tmp.DataDTRMode = (cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_DATA_DTR_ENABLE
	cmd_tmp.DataDTRMode = (cfg_rate != MSPI_DATA_RATE_SINGLE) ? HAL_XSPI_DATA_DTR_ENABLE

	(cfg_rate == MSPI_DATA_RATE_DUAL) ? HAL_XSPI_DQS_ENABLE : HAL_XSPI_DQS_DISABLE;
	(cfg_rate != MSPI_DATA_RATE_SINGLE) ? HAL_XSPI_DQS_ENABLE : HAL_XSPI_DQS_DISABLE;

drivers: mspi: Support MSPI driver for STM32. #96670

Are you sure you want to change the base?

drivers: mspi: Support MSPI driver for STM32. #96670

Uh oh!

Conversation

ExaltZephyr commented Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

erwango Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ExaltZephyr Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tpambor left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tpambor Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erwango commented Nov 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FRASTM left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ExaltZephyr commented Nov 19, 2025

Uh oh!

erwango commented Nov 19, 2025

Uh oh!

ExaltZephyr commented Sep 28, 2025 •

edited

Loading

erwango Oct 2, 2025 •

edited

Loading

ExaltZephyr Nov 19, 2025 •

edited

Loading

tpambor Nov 19, 2025 •

edited

Loading

FRASTM left a comment •

edited

Loading