memc: stm32_xspi_psram: Fix compilation issues for STM32H5 series

[tpambor]

The STM32H5 series has only a single XSPI interface and does not support the XSPI manager, the related MaxTran parameter and 16-bit IO. Configure these only if they are supported by the chip.

Fixes #99191

[erwango]

Thanks. Btw, it is rather more adding driver support to H5 than fixing a mere bug. Also, it would be nice to be sure there is a configuration in tree allowing to build it. Can it be enabled on a board ? If not, would you mind providing a configuration in tests/drivers/build_all

[JarmouniA]

H5 has an OctoSPI controller (that's XSPI (JESD251C) standard compliant, which is not the same as having an XSPI controller like the N6 for ex.), that's why many things aren't available in the HAL.
To me, this driver should be checking the compatible of the parent of its device node, and decide what to use based on that.

[tpambor]

H5 has an OctoSPI controller (that's XSPI (JESD251C) standard compliant, which is not the same as having an XSPI controller like the N6 for ex.), that's why many things aren't available in the HAL. To me, this driver should be checking the compatible of the parent of its device node, and decide what to use based on that.

@JarmouniA Regarding XSPI Manager and related features, I followed how it is done for the flash side in flash_stm32_xspi.c

zephyr/drivers/flash/flash_stm32_xspi.c

Lines 2522 to 2526 in 2a9f214

	#if defined(HAL_XSPIM_IOPORT_1) || defined(HAL_XSPIM_IOPORT_2)
	.MemorySelect = ((DT_INST_PROP(0, ncs_line) == 1)
	? HAL_XSPI_CSSEL_NCS1
	: HAL_XSPI_CSSEL_NCS2),
	#endif

With respect to 16-bit IO support, this could be handled differently. Currently, this driver only handles AP PSRAMs (HAL_XSPI_MEMTYPE_APMEM). I am looking to add support for Macronix PSRAMs as well (HAL_XSPI_MEMTYPE_MACRONIX_RAM). IMHO, the best way would be to refactor the current PSRAM driver and split the common and the PSRAM chip specific parts, similar as to how this is done for FlexSPI, https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/memc/memc_mcux_flexspi_is66wvq8m4.c, https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/memc/memc_mcux_flexspi_aps6408l.c, etc. So this setting would be part of the PSRAM-specific device tree node. But I am open to other suggestions. I wanted to send the refactor as a follow-up PR as this PR is sufficient to make it work with AP PSRAMs. And in a second PR I will add support for PSRAMs from other vendors.

Also, it would be nice to be sure there is a configuration in tree allowing to build it. Can it be enabled on a board

@erwango I am not aware of a board with STM32H5 and PSRAM in-tree, so I will add it to tests/drivers/build_all.

[etienne-lms]

For consistency in commit message header lines, prefer
drivers: memc: stm32xspi_psram: ...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[erwango]

IMHO, the best way would be to refactor the current PSRAM driver and split the common and the PSRAM chip specific parts, similar as to how this is done for FlexSPI [...]

Long term solution on this is to make use of upcoming MSPI API, which splits device and controllers implementations. See
#96670
For short term, I think we need to find a trade of by getting the maximum out of the current driver but avoid to spend too much time on it.

[tpambor]

Long term solution on this is to make use of upcoming MSPI API, which splits device and controllers implementations. See #96670 For short term, I think we need to find a trade of by getting the maximum out of the current driver but avoid to spend too much time on it.

Thanks for pointing this out. I wasn’t aware of that PR. The MSPI API approach definitely seems like the right direction. I will look into utilizing it to add support for additional PSRAMs.

[erwango]

#96670 has now been merged.