On 17/12/21 06:27AM, Tudor.Ambarus@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.