drivers: flash_mspi_nor: Apply a few improvements #93093
Conversation
Get parameters for standard commands and requirements for enabling Quad and Octal modes from dts uint8-arrays containing data read from SFDP tables for particular flash chips. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
- Use standard operation codes and parameters from SFDP for handling most of the used commands (except for read, write, and erase for now) - Use common functions for reading and writing of status registers and for enabling write operations - Switch IO mode in a common function that perfors a transfer and do it only when required for a given command Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Complete implementation of quad_enable_set() by adding support for all possible Quad Enable Requirements (QER) as specified by the SFDP JEDEC standard (JESD216). Add also corresponding octal_enable_set() to handle Octal Enable Requirements. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add implementation of the most common Soft Reset routine (sequence of reset enable instruction 0x66 and reset instruction 0x99). Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Using a GPIO reset for a flash chip that has a dual function pin (RESET# or SIO3) and is to be used in Quad mode is rather a bad idea and so is clearing of the Quad Enable bit at every initialization of the flash driver, since this bit is usually non-volatile, so such operation means unnecessary wearing of the flash chip. Soft Reset should be use instead in such case. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
github-actions
bot
requested review from
de-nordic,
jaz1-nordic,
kl-cruz,
magp-nordic,
nika-nordic,
rghaddab and
swift-tk
|
There was a problem hiding this comment.
I'm not specifically opposed to using SFDP for this driver, but I honestly doubt we are going to get the best performance out of most flash devices with this method. My primary concern is that not all flash devices actually implement SFDP discoverability, particularly for octal or quad settings (as least as far as I've seen)
Do you have any thoughts on the approach I took in #88920? I think these methods can coexist if they need to, but I personally feel like we may just be better off using compatibles for flash settings at build time, and JEDEC ID to select flash settings at runtime.
There was a problem hiding this comment.
This reminds me of the attempt I took adding mspi_nor... The global storage needed by SFDP would explode flash_data as we continue to add more DWORDS.
Therefore, IMO, it would better the SFDP can have its own data struct and separate .c file and then we could have it enabled through Kconfig.
The SFDP should be used for generic flash that does support it and enable through a Kconfig and dts property. With SFDP, it should load cmd and other properties through DWORDS instead of using the generic or the vendor table. It is essentially a different way of runtime probing, so I think it could coexist well provided that it doesn't get in and mess up the core all over the place. |
Apply a few improvements in the flash_mspi_nor driver, most notably:
See the individual commit messages for details.