Hi all On Tue, Sep 9, 2025 at 7:08 PM Raghavendra, Vignesh <vigne...@ti.com> wrote: > > > > On 9/9/2025 5:37 PM, Jagan Teki wrote: > > On Tue, Sep 9, 2025 at 3:43 PM Miquel Raynal <miquel.ray...@bootlin.com> > > wrote: > >> > >> Hello, > >> > >> On 02/07/2025 at 11:23:13 +02, Miquel Raynal <miquel.ray...@bootlin.com> > >> 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 <miquel.ray...@bootlin.com> > >> > >> 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. > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __________________________________ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
