Hi Michael, On 10/09/2025 at 07:28:22 +02, Michael Nazzareno Trimarchi <[email protected]> wrote:
> Hi all > > On Tue, Sep 9, 2025 at 7:08 PM Raghavendra, Vignesh <[email protected]> wrote: >> >> >> >> On 9/9/2025 5:37 PM, Jagan Teki wrote: >> > On Tue, Sep 9, 2025 at 3:43 PM Miquel Raynal <[email protected]> >> > wrote: >> >> >> >> Hello, >> >> >> >> On 02/07/2025 at 11:23:13 +02, Miquel Raynal <[email protected]> >> >> wrote: >> >> >> >>> These chips are internally made of two/four dies with linear addressing >> >>> capabilities to make it transparent to the user that two/four dies were >> >>> used. There is one drawback however, the read status operation is racy >> >>> as the status bit only gives the active die status and not the status of >> >>> the other die. For commands affecting the two dies, it means if another >> >>> command is sent too fast after the first die has returned a valid >> >>> status (deviation can be up to 200us), the chip will get corrupted/in an >> >>> unstable state. >> >>> >> >>> The solution adopted here is to iterate manually over all internal >> >>> dies (which takes about 30us per die) until all are ready. This approach >> >>> will always be faster than a blind delay which represents the maximum >> >>> deviation, while also being totally safe. >> >>> >> >>> A flash-specific hook for the status register read had to be >> >>> implemented. Testing with the flash_speed benchmark in Linux shown no >> >>> difference with the existing performances (using the regular status read >> >>> core function). >> >>> >> >>> As the presence of multiple dies is not filled in these chips SFDP >> >>> tables (the table containing the crucial information is optional), we >> >>> need to manually wire the hook. >> >>> >> >>> This change is adapted from Linux. >> >>> >> >>> Link: >> >>> https://lore.kernel.org/all/20250110-winbond-6-12-rc1-nor-volatile-bit-v3-1-735363f8c...@bootlin.com/ >> >>> Signed-off-by: Miquel Raynal <[email protected]> >> >> >> >> Same question for this one, no feedback for the past 2 months, I'm not >> >> sure who's supposed to take these, Jagan and Vignesh you are marked M: >> >> in maintainers, any chances this can get it? >> > >> > Unfortunately, I was off quite some-time. Need little bit of time. >> > Vighnesh is off for years. >> >> Thats not true. I dont have access to U-Boot SPI trees. So patches have >> been flowing through individual "platfor/SoC" maintainers trees >> unfortunately. Tom picks the patches from TI contributors once >> me/Nishanth Acks where as AMD/Xlinix bits have been picked up by Michal >> Simek and so on... >> >> Happy to help out if you help to manage a merge window every now and >> then or just review things. Most of the SPI NOR/NAND follow from linux >> where its reviewed by set of maintainers and tested (example this one is >> tested on TI board). > > I will go through the patches over the weekend and review them. I will > prepare a branch > spi-nor-next and try to ask to test from there > > Michael > >> >> > In the meantime, Michael will help in >> > review but need help on testing. >> > >> > Thanks, >> > Jagan. >> I still do not see these patches in any upstream tree. Am I missing something? If I may, these patches have been reviewed during the Linux contribution process already, and submission happened in July, almost 5 months ago. Thanks, Miquèl
