Hi Rajat,
On 26.10.18 11:59, Rajat Srivastava wrote:
<snip>
From what I read, Rajat's method is to extend the controller driver to support read SFDP and default to 4-byte mode if supported, or overwritten by user's flag. Stefan's method is to read 4-byte status bit and doesn't change controller driver.
Is the default value of this 4-byte status bit valid and correct for all cases?
Rajat, without your patch set, does Stefan's solution work for your board?
York
No. Stefan's changes are specific to his boards and is not applicable on ours. Stefan's patch is to support only certain flash that are factory strapped to work in 4-byte addressing modes only and will default to old method if such a flash is not found.
That is not 100% correct. The flash does not need to be "factory strapped" to this 4-byte mode. It needs to be configured to this 4-byte mode. And this is also the case for example, when the ROM bootloader configures the flash this way or a soft-reboot (without hard flash chip reset) reboots into U-Boot after the flash was configured to 4-byte mode in Linux.
And it supports multiple vendors and can easily be extended to support more. The only thing needed is the detection of the 3-byte vs 4-byte address mode. But please note that it currently does not actively switch from 3-byte to 4-byte mode. This could be added though if needed / wanted.
The flashes on our boards (and also other vendor's board) will not work with Stefan's patch.
My patch can handle flashes with address widths of 3-byte, 4-byte or both. It also takes a more generic path (as opposed to supporting only specific flash models) by parsing SFDP standard parameters and then deciding what address width is to be used.
I still don't see why each and every SPI controller driver needs to be extended to support this SFDP parameter reading. Can't this be handled by some generic (read common) code part in the SPI flash infrastructure?
Thanks, Stefan