stm32n6: Fix xspi devices configuration #95153
Conversation
… HCLK5 Fix copy/paste issue on XSPI_SEL macro and use HCLK5 as kernel clk. This has no functional impact on NOR as HCLK5 is the default clk which was used due to the copy/paste error. Remove now useless ic3 nodes. Signed-off-by: Erwan Gouriou <[email protected]>
zephyrbot
requested review from
de-nordic,
djiatsaf-st,
etienne-lms,
FRASTM,
gautierg-st,
GeorgeCGV,
marwaiehm-st,
mathieuchopstm and
rghaddab
This commit is fixing configuration of mx66uw1g45g NOR when working at 200MHz. According to its specification, when running at 200MHz, this memory should use a Number Dummy Cycles configuration of 20 (DC bits in CFGR2), which is the device's default configuration. Applying the 66MHz configuration as done today was preventing flash to run at frequency higher than 100Mhz. This commit doesn't solve the more generic problem of this driver which is applying this 66MHz configuration universally, irrespective of the frequency and the memory device, but fixes the configuration which was reported broken today. Providing a global change would require starting a clear split between XSPI controller configuration an bus device configuration, which is what new MSPI API intend to solve, so this will be tackled once this driver will be available. Signed-off-by: Erwan Gouriou <[email protected]>
erwango
force-pushed
the
fix_n6_nor_clk
branch
from
08fb9b2 to
b209c6d
Compare
|
|
|
Not a regression due to these changes from what I can test. Removing |
| if (dev_cfg->max_frequency == MHZ(200)) { | ||
| /* Use memory default value */ | ||
| return 0; | ||
| } |
There was a problem hiding this comment.
Is this a N6-specific hack? If so, a if (IS_ENABLED(CONFIG_SOC_SERIES_STM32N6X) should be added
There was a problem hiding this comment.
This configuration is related to the specific NOR device, not the SoC.
As mentioned in the commit description, this fix is definitely not ideal, but these flash drivers are not designed to take into account devices specifics, so I'm minimizing the impact.
In its current shape, this piece code is not correct for some of the configuration that are already in tree, but no issue were reported, so I prefer not touch it more.
A proper change would require to have knowledge about the memory type and implement the full table for each device. In the end what we need is a proper split between devices and controllers ... which will come with MSPI drivers. It would not be duplicated work to start this task on this driver.
Not satisfying but more reasonable from my point of view.
This PR targets to fix 2 known issues around xspi devices configuration on stm32n6 based boards:
For this second issue, I chose fixing the specific issue of the NOR configuration on the 2 impacted boards.
As metionned in the commit message, fixing the larger problem of configuring xspi devices more closely according to their type and specification is what MSPI API intends to solve, so I prefer let this general issue on MSPI driver development and for now
focus on fixing reported issues on flash xspi driver.