[WIP] stm32 mspi drivers for the MSPI flash and controller #78186
Conversation
FRASTM
changed the title
FRASTM
force-pushed
the
mspi_stm32
branch
4 times, most recently
from
6dd0042
to
c574a3d
Compare
|
reading external NOR at offset 0 in spi/str mode : |
FRASTM
force-pushed
the
mspi_stm32
branch
7 times, most recently
from
8ff65f9
to
4617600
Compare
FRASTM
force-pushed
the
mspi_stm32
branch
12 times, most recently
from
a63ea6e
to
2e07eb4
Compare
FRASTM
force-pushed
the
mspi_stm32
branch
2 times, most recently
from
49f0d98
to
e23716f
Compare
Add the mspi-device and mspi-flash controller bindings for the stm32 devices. Signed-off-by: Francois Ramu <[email protected]>
Replace the xpsi by the mspi node in the DTS of the stm32h5 serie Signed-off-by: Francois Ramu <[email protected]>
Enable the stm32 MSPI controller based on the xspi peripheral Signed-off-by: Francois Ramu <[email protected]>
Enable the MSPI NOR multi-SPI flash device accessed through a mspi controller. Signed-off-by: Francois Ramu <[email protected]>
Declare the mspi node of the stm32h573i_dk in place of the xspi. New properties are declared according to the mspi-controller.yaml. Only SPi/STR supported yet. XIP not supported yet. Signed-off-by: Francois Ramu <[email protected]>
Add the configuration and overlay files to run the testcases tests/drivers/mspi/api and tests/drivers/mspi/flash on the stm32h573i_dk target Now exclude from the samples/drivers:spi_flash Signed-off-by: Francois Ramu <[email protected]>
zephyrbot
added
area: MSPI
area: Flash
platform: STM32
zephyrbot
requested review from
de-nordic,
decsny,
erwango,
galak,
gautierg-st,
GeorgeCGV,
kartben,
marwaiehm-st,
mathieuchopstm,
nashif,
rghaddab and
swift-tk
There was a problem hiding this comment.
I will start by thanking your support for the MSPI API. @FRASTM
After taking a brief look and I think there are quite a lot of work to be done for both the controller and device driver.
Additionally, I would like to stress one more time that it is important to shroud hardware differences in the device driver. In this case, it is the flash_mspi_nor_mx.c. So that we may have shared drivers that can be used across platform.
| } | ||
|
|
||
| /* Command to the flash for reading status register */ | ||
| static int flash_mspi_nor_mx_status_read(const struct device *flash, uint8_t status) |
There was a problem hiding this comment.
So the user context way did not work out?
The methods(auto polling) introduced in this function is not a common one thus should not appear like this in a shared driver as others(controllers) will not be able to use this driver.
Also I'm confused with the use of async PIO but does not register callback?
|
|
||
| /* Function to read the flash with possible PIO IT or DMA */ | ||
| static int flash_mspi_nor_mx_read(const struct device *flash, off_t offset, void *rdata, | ||
| size_t size) |
There was a problem hiding this comment.
You will need to consider controllers that does not support XIP read.
The config CONFIG_MSPI_XIP is used to indicate a controller's support on that.
It was my bad that I did not include those config in my PR for the atxp032 flash driver and will be fixed in the near future. You should consider adding them like this #79513
| return -EIO; | ||
| } | ||
|
|
||
| /* At this time only set the io_mode and data rate */ |
There was a problem hiding this comment.
You can't assume that only setting IO mode and data rate is enough.
Different controller have different defaults when it comes to the member of struct mspi_dev_cfg. Even the initialization process may needed different values. So they should specified and configure clearly.
Thus this should be a CONFIG_ALL.
| /* | ||
| * We should check here that the mem is ready, | ||
| * configure it according to the io-mode/data-rate | ||
| * MSPI_DEVICE_CONFIG_ALL will overwrite the previous config of the MSPI |
There was a problem hiding this comment.
That is the point actually. The initial mspi_dev_config is only for device initialization and the settings should be power on default/OTP default. You can have several mspi_dev_config if needed be but the final mspi_dev_config should bring it to the target operational state.
| data->packet.address = offset; | ||
| data->packet.data_buf = rdata; | ||
| data->packet.num_bytes = size; | ||
| /* ASYNC transfer : use callback on Irq if PIO, meaningless with DMA */ |
There was a problem hiding this comment.
Not sure I understand the reason why DMA is not used. Now that I think of it, maybe we should make it configurable for different controllers or users.
| /* | ||
| * async + MSPI_PIO : Use callback on Irq if PIO | ||
| * sync + MSPI_PIO use timeout (mainly for NOR command and param | ||
| * MSPI_DMA : async/sync is meaningless with DMA (no DMA IT function)t |
There was a problem hiding this comment.
Does mspi_transceive return before DMA completes the transfer? If so, it is async. The complete status is updated through callback.
this PR is introducing the MSPI driver device a controller for the stm32 mcus : stm32H5 serie
---> compat is
mspi_nor_mx25---> compat is
st,stm32-mspi-controllerBuild an run the samples/drivers/mspi/mspi_flash/ on stm32h573i_dk disco kit