From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 5 Mar 2013 12:45:15 -0500 Subject: [U-Boot] [PATCH 00/12] cmd_sf: Add support for read and write instructions In-Reply-To: References: <1356952428-19824-1-git-send-email-jagannadh.teki@gmail.com> <20130304210858.GD25797@bill-the-cat> <51362685.4010807@ti.com> Message-ID: <51362F2B.9030006@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----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 wrote: On > 03/05/2013 12:00 PM, Jagan Teki wrote: >>>> Hi Tom, >>>> >>>> On Tue, Mar 5, 2013 at 2:38 AM, Tom Rini >>>> 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. - -- 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-----