On 17/12/21 06:27AM, tudor.amba...@microchip.com wrote: > On 12/16/21 8:45 PM, Pratyush Yadav wrote: > >>>> > >>>>> > >>>>>> SFDP signature to determine the mode in which the flash is configured: > >>>>>> ''' > >>>>>> try to read the SFDP signature (see 6.1) in 4-4-4 mode, if that fails > >>>>>> try 2-2-2 mode, and if that fails try 1-1-1 mode. For Octal devices, > >>>>>> these typically support SFDP read operation in both 1S-1S-1S mode and > >>>>>> 8D-8D-8D mode. If the host controller does not know exactly which > >>>>>> protocol mode is used for SFDP in 8D-8D-8D mode, this information can > >>>>>> be > >>>>>> found by reading SFDP in 1S-1S-1S mode first. (To read an unknown > >>>>>> device > >>>>>> directly in 8D-8D-8D mode, the host controller may read from address 0, > >>>>>> and count the number of dummy clocks required before the SFDP signature > >>>>>> is received.) > >>>>>> ''' > >>>> > >>>> Below is the approach for the flashes that are not SFDP compliant: > >>>> > >>>>>> If the flash does not support SFDP at all, one should introduce > >>>>>> dedicated > >>>>>> configs for each reset type and issue just the needed reset command. > >>> > >>> There are some problems with this approach. What if we have two flashes > >>> on the board and both use different reset types? How do we figure out > >>> which reset to apply? This applies to the current implementation as > >>> well. If there are two flashes then it will issue the reset to both even > >>> if one of them does not support/need it. > >> > >> One would have to choose the NOR manufacturer with care next time. If we'll > >> have to statically define the reset type for both the flashes, there's > >> nothing > >> much we can do. Maybe if you have a gpio reset line connected to the flash > >> you > >> can toggle that instead. > > > > Or we can specify the reset type in the device tree? That should neatly > > solve the problem I believe. > > > > It is surely an approach to consider. The downside with it is that people > might > abuse it, and use it regardless if the reset type is defined in SFDP or not. > Do we care?
I am not sure to be honest. Let's think through that once the problem actually comes up I suppose. -- Regards, Pratyush Yadav Texas Instruments Inc.
