Add MSPI + flash driver for the TI K3 platform

[m-braunschweig]

This PR adds support for MSPI and the Infineon S25H flash on the TI K3 platform. It is tested with the onboard flash of the AM2434 launchpad. (PR for the driver flash driver: #88446). It's now part of this PR.

For running the code on the AM243x Launchpad this branch is used. Until the AM243x Launchpad is generally supported this shouldn't be merged. However I would still like some early review to speed up merging later. Especially on how to potentially handle the timeout parameter better and whether I interpreted the unit being microseconds right.

The driver itself is pretty basic (e.g. no async and XIP support) but enough for running MCUboot on the board (by loading the image into SRAM).

Edit: Mention that this PR also includes the S25H flash driver now

[gramsay0]

k_uptime_get is the current uptime in milliseconds, calling k_cyc_to_us_floor32 is probably not what you want.
The timeout parameter is not well documented, but it appears to be in milliseconds (from looking at other drivers)

[swift-tk]

It is defined in kconfig

zephyr/drivers/mspi/Kconfig

Line 35 in fe6366b

int "Completion timeout tolerance (ms)"

[gramsay0]

Ahh my bad, I'm not familiar with mspi driver API and only looked at the struct definition. It would be helpful to mention it there too

[m-braunschweig]

Ok I will update that to use milliseconds everywhere in the MSPI driver. I will also switch over to k_uptime_get so I don't need the conversions anymore

[m-braunschweig]

Also: How are the Kconfig option and timeout field correlated? For me it seems quite unclear since it's used both in flash and MSPI drivers, additionally to the already existing timeout field

[swift-tk]

Also: How are the Kconfig option and timeout field correlated? For me it seems quite unclear since it's used both in flash and MSPI drivers, additionally to the already existing timeout field

The Kconfig option is offered as a setting to the controllers for its maximum timeout allowence. The timeout field is variable in the transfer struct but should not exceed this Kconfig option.

[gramsay0]

Seems like the chip select delay should come from struct mspi_ce_control

[swift-tk]

No, not really. struct mspi_ce_control is for software controlled CE. However, I do think that this CE timing maybe peripheral device specific but not transfer specific. NXP have a similar setting as well. We can try add that to struct mspi_dev_cfg
Another option is to slide it in through struct mspi_timing_cfg along with your custom timing parameters.

[m-braunschweig]

For now I'm going to add it to the mspi_dev_cfg to be read from the devicetree
I'm going to add a custom timing config

[gramsay0]

There are a number of mentions of "flash" in this file that should be removed.
This driver may be used for things other than flash memory

[m-braunschweig]

Will update that. They are there because it initially started as a standalone flash driver

[gramsay0]

Consider using GENMASK/FIELD_PREP/FIELD_GET, the macro concatenations (TI_K3_OSPI_##reg##_##field##_FLD_OFFSET) make it difficult to navigate to the register definitions

#define TI_K3_OSPI_CONFIG_REG_IDLE_MASK GENMASK(31, 31)

uint32_t config_reg = sys_read32(base_addr + TI_K3_OSPI_CONFIG_REG_OFFSET);
uint32_t idle = FIELD_GET(TI_K3_OSPI_CONFIG_REG_IDLE_MASK, config_reg);

[m-braunschweig]

I would prefer to keep the macro since it keeps the code in the mspi_ti_k3.c quite short. I think I will add comments that explains the macros and register definitions

[gramsay0]

Add DEVICE_MMIO_RAM; as the first field

[swift-tk]

Are you not going to add any soc DTS for the controller?
To ensure compile across PRs, it is best to add the controller to one of the example or testcase.

[swift-tk]

It is used as part of device_id.

[m-braunschweig]

Can you explain what you exactly mean with that?

Currently this driver uses hardware implemented chip select in the OSPI_CONFIG_REG via the PERIPH_CS_LINES_FLD field. There are 4 dedicated pins for that and they are only referenced by the numbers 0..3, which I directly use in the mspi_ti_k3_dev_config function. When I would use ce-gpios with phandle to the GPIO pins I think it would be necassary to do software CS control.

[swift-tk]

Can you explain what you exactly mean with that?

Currently this driver uses hardware implemented chip select in the OSPI_CONFIG_REG via the PERIPH_CS_LINES_FLD field. There are 4 dedicated pins for that and they are only referenced by the numbers 0..3, which I directly use in the mspi_ti_k3_dev_config function. When I would use ce-gpios with phandle to the GPIO pins I think it would be necassary to do software CS control.

ce-gpios can be used to for software CE control, but it is also used as part of the device id, see struct mspi_dev_id which is filled by MSPI_DEVICE_ID_DT. So you would have to have at least a ce-gpio defined in controller dts. The dev_id should be used to validate the peripheral(child) device within the controller, although some choose not to as no plan to support software-multiperipheral function. i.e. switching between child devices by software under the same controller.
If your controller is capable of switching by hardware CE number, then you can pass that 0~3 number in struct mspi_dev_cfg.ce_num .
I do recognize there might be a compatiblity problem if your CEs are not within one of your GPIO alternate function but dedicated pin. But we will fix it when we get there.

[m-braunschweig]

For now I removed the ce-gpios part from the bindings. However it's still ignored in the driver and added the requirement that GPIO has to be selected in the Kconfig

[swift-tk]

No, not really. struct mspi_ce_control is for software controlled CE. However, I do think that this CE timing maybe peripheral device specific but not transfer specific. NXP have a similar setting as well. We can try add that to struct mspi_dev_cfg
Another option is to slide it in through struct mspi_timing_cfg along with your custom timing parameters.

[swift-tk]

It is defined in kconfig

zephyr/drivers/mspi/Kconfig

Line 35 in fe6366b

int "Completion timeout tolerance (ms)"

[m-braunschweig]

Are you not going to add any soc DTS for the controller?
To ensure compile across PRs, it is best to add the controller to one of the example or testcase.

I will add that to this PR when the AM2434 SoC and AM2434 Launchpad are officially supported. The AM2434 SoC support is currently being done in #87321. After that is merged I will add the AM243x LaunchPad board and after that I can also add the MSPI flash test to this PR. Before that I will only add it to the https://github.com/siemens/zephyr/commits/mika/ti/ti-am2434-native-boot/ branch

[swift-tk]

@m-braunschweig You should squash the 13 commits into 2, one for the controller driver, one for the flash driver. That is zephyr PR policy.

[m-braunschweig]

@swift-tk done.
My original thought for adding extra commits instead of amending them was that this PR is still somewhat WIP / a draft and that it would make reviewing new changes a bit easier. The "final" squash could then have been done when leaving the draft stage.

[m-braunschweig]

Also I have some more questions to the MSPI driver API:

• The TX and RX delay for MSPI devices can be configured both in the mspi_dev_cfg that's used in mspi_dev_config() and it's additionally part of the mspi_xfer struct that's given on every transfer request. In which cases should which value be honored?
• The Infineon S25H flash has different delays for different commands. How should that be handled in the devicetree since there is only one rx-dummy/tx-dummy field? One option would be to add all of them in the devicetree binding, however the original rx-dummy/tx-dummy comes from the generic MSPI device binding
• How should read-command and write-command be handled in this case? Should they use the opcode for single or quad mode transfers?

For the devicetree things I was unsure about I currently check during build time that they are unset. However I don't really like that solution and would be happy to hear about ideas to improve it

[swift-tk]

• The TX and RX delay for MSPI devices can be configured both in the mspi_dev_cfg that's used in mspi_dev_config() and it's additionally part of the mspi_xfer struct that's given on every transfer request. In which cases should which value be honored?

The mspi_dev_cfg contains device specific controller settings. There are cases where a device is initialized with mspi_dev_config() but does not uses mspi_xfer at all(e.g psram or XIP mode) or it needs to use different cmds with different settings when using mspi_xfer. The overlapping members are only the transfer related settings and should not involve changing device state.

The settings given to mspi_xfer takes precedence over mspi_dev_cfg in the context of the peripheral device driver, so tracking the state change with a global mspi_dev_cfg is desirable as the device would have to repeatedly obtain controller access and tries to override controller settings in each device APIs.

• The Infineon S25H flash has different delays for different commands. How should that be handled in the devicetree since there is only one rx-dummy/tx-dummy field? One option would be to add all of them in the devicetree binding, however the original rx-dummy/tx-dummy comes from the generic MSPI device binding

The device tree properties represent the target configuration that the device will run on most of the time. In the case of flash memory, it represents settings when conducting memory write and read. The default settings for device initialization should be stored as const and possibly used for all register access to maintain maximum compatibility as they should typically be low speed.

• How should read-command and write-command be handled in this case? Should they use the opcode for single or quad mode transfers?

If your target operating mode is single mode, then swap the cmds in device tree with cmds used in single mode and the same way with quad mode. Mode switching should be done by mspi_dev_config() and device state change should be tracked by the device driver itself if some commands are not available in one mode or the other. IMO, one would only need one target operating condition for a specific device throughout the software program cycle. So intermediate states should be managed by the device driver.

For the devicetree things I was unsure about I currently check during build time that they are unset. However I don't really like that solution and would be happy to hear about ideas to improve it

You have to check it each time when a config is passed from device driver. To reduce unnecessary config from repeated mspi_dev_config() calls and to maintain maximum compatibility, you should use the acquire and release function in the existing flash mspi drivers.