Jonathan,

On 10/28/2009 03:45 PM, Jonathan Haws wrote:

Looking through our notes and talking with the engineer 
who was performing the tests, it was exactly that - MTD was waiting
for a signal that was produced differently than the hardware 
ready signal.  By simply polling the flash until the hardware
ready signal toggled we were able to get a much faster read and write speed.
Granted, most of our signals are being sent through a CPLD,
so that may be why MTD did not work as well.

even if your problem is solved I'd like to understand this performance issue.
I had a look into the datasheet of the S29GL Mirrorbit flash by Spansion as an example. They provide a dedicated pin RY/BY#, which signals the end of an embedded algorithm (erase or programming). While figure 11.9 shows no timing advance of RY/BY# against Dout on the data line, figure 11.12 has one of unspecified length between RY/BY# and the end of data toggling.

If you had a 10-fold slowdown with MTD, either the CPLD really slows down the read access to the flash or maybe your custom driver uses some acceleration (write buffer programming,
unlock bypass, accelerated program with 12V on the WP#/ACC pin) while MTD does not.

Which kernel version and flash device did you use in this comparsion?


Regards,
Jörg.