Looking through our notes and talking with the engineer=20
who was performing the tests, it was exactly that - MTD was waiting
for a signal that was produced differently than the hardware=20
ready signal.  By simply polling the flash until the hardware
ready signal toggled we were able to get a much faster read and write spe=

ed.

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 issu=
e.
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 ti=
ming 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 t=
he read access to the flash or maybe your custom driver uses some accelerat=
ion (write buffer programming,
unlock bypass, accelerated program with 12V on the WP#/ACC pin) while MTD d=
oes not.

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

We were using VxWorks when we did the comparison, so there may be a problem=
 in their driver.  We are using unlock bypass by the way.  Our flash chip i=
s from Spansion.  I do not have the datasheet right with me, so I do not ha=
ve the part number.