> On Tue, 2009-10-27 at 16:52 -0600, Jonathan Haws wrote: > > > Jonathan Haws wrote: > > > > I had thought about using MTD, but decided against it because > with > > > > previous benchmarking that we did with MTD and our custom > driver, > > > we > > > > found that our custom driver was about 10x faster. > > > > > > Ouch. Any idea where the slowdown is coming from? > > > > From what I remember (I would have to dig up notes to make sure) > it is something to do with MTD looking for a signal to go high that > is processed a bunch before MTD even sees it. Our flash produces a > hardware ready signal that we are triggering off of to move on. MTD > took much longer to report to us that the hardware was ready. > > > > Thanks > > > > It would be interesting to know in more detail what is was. If we > have a > 10x performance increase hiding from for us I would be very > interested > in knowing where it is. > > Are you using some custom command to the flash that the generic chip > drivers in Linux is not yet supporting ?
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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
