Hi Tom,
On Tue, Mar 5, 2013 at 11:15 PM, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/05/2013 12:21 PM, Jagan Teki wrote:
Hi Tom,
On Tue, Mar 5, 2013 at 10:38 PM, Tom Rini trini@ti.com wrote: On 03/05/2013 12:00 PM, Jagan Teki wrote:
Hi Tom,
On Tue, Mar 5, 2013 at 2:38 AM, Tom Rini trini@ti.com wrote:
On Sat, Mar 02, 2013 at 01:59:38PM +0530, Jagan Teki wrote:
[snip] > Since these changes I have sent long back, I am just > re-modified the framework to add new features at the same > time with backward comparability for current commands. > > Current command setup: sf write sf read sf update > > Changed command set: [no changes in the argument count] > sf write --- current command sf write.pp -- same as > sf write sf write.qp -- quad program > > sf read -- current read sf read.af --- array flast > read, same as sf read sf read.as -- array slow read sf > read.do --- dual out sf read.qo -- quad out sf read.dio > -- dual io sf read.qio -- quad io > > sf update -- current update sf update.pp.af -- write > page program, read array fast, same as sf update sf > update.pp.as - write page program, read array slow sf > update.pp.do - write page program, read dual out sf > update.pp.qo - write page program, read quad out sf > update.pp.dio - write page program, read dual io sf > update.pp.qio - write page program, read quad io sf > update.qp.af - write quad program, read array fast sf > update.qp.as - write quad program, read array slow sf > update.qp.do - write quad program, read dual out sf > update.qp.qo - write quad program, read quad out sf > update.qp.dio - write quad program, read dual io sf > update.qp.qio - write quad program, read quad io > > Though it seems to be lengthy, but may useful with lot > of combinations from user. My intention is to use the > existing argument count with changes in the command set.
Are there cases where for the current device we're operating on that can handle more than one of these, aside from fast or slow? And do we really need to offer both fast and slow?
Yes as per as I know spansion, numonyx and winbond flashes are supporting all the operation modes that I listed above.
These are very generic w.r.t above flashes.or I can say these are commonly available modes.
And when hooked up via whichever SPI controller you have, all of those modes are also available and we can't really "guess" about using a faster mode?
I didn't get you. In general, u-boot should provide all the possible operation modes and the choice should be up to user. Please elaborate as I seem to be missing something.
Unless I'm missing something (or we're talking about different things), you have a SPI flash that do quad (or dual) read/write. But it also has to be connected to a controller that talks quad (or dual).
So is there any way we can make sf read/write/update be the fastest supported (and why do we want fast and slow quad programming?) by the controller and chip? I can see having to do "sf read.qp.qf ..." and so forth leading to some less than desired user interaction.
Okay.. what I understand is - Currently, all the flash supported commands are provided to user as choice. what what i suppose to implement. He needs to choose the best option based on what the controller and chip connected supports. I guess your idea is to dynamically perform the fastest read/write command based on fastest command supported by controller and chip. I don't know how to support this.
Thanks, Jagan.
Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRNi8rAAoJENk4IS6UOR1WkAsP/3T7bdlRJAWtYFuUFoqF/Ofu 4LZZGcab75WwW7xUlHxct7oH8j4DE3c+PYT+RmxdpbhW7Av6VQJ9acDWRJE6upao 3M4WvTlDD2uyUEyMeWQWtgdcLNMP5eJcZ1CHP7MKYklW2qsdIbCZ4SnqseDqCIyb 7u2PPtCNWSVIn6tpihaM7hEho8KWa1YH7nnOfqF7V2629Tyah9IxX83VFLyP4Ujz k/qRenQQN7CcKsyaSEnDNH3ZWH1FN0asrXZyxOcEUVaIca+pq4Z7QtmufS2I+e/b DV2HUmI5UsC0USQrmaD21ais4taz4hZVNowEGcvw8Go0AnLkB7r+epksFr+Qf/T0 jm1XT3+pNEN4kt+Rgsuf+97ovOlNBWvIGmrYO104aDVg3+IVc8lkeb7STAKIAXah d+WAA8kq36O0gj0enR4wsf96bzmn0aVUqBtuKmdwFP+W1U+q1Es/JodFW5niKMWn i2VEMFZ0Oww+7VzWcIg5tT5t2FtkLkHRg+7QkFP0BIvd1+7rKpuEE+ntd9UBjFpr ZzaC65D/aPtv9LvmTqOfRlk6nGxXmFJQqWbd0sv5hFEPp4pHMlkr8queKdRItW1E dYu98kvcETdAI3AfgLcsyzjNOzPODRdlUiUmCDhcHW2Waxby7pmreeEdSJoHGeZt QszhTVaNWgVq0qAFQVIc =1CRc -----END PGP SIGNATURE-----