Incorrect struct onfi_params definition

[Warner Losh]

On Nov 15, 2013, at 10:39 AM, Ian Lepore wrote:

> On Wed, 2013-11-13 at 23:32 +0100, kristof at sigsegv.be wrote:
>> Hi Ian,
>> 
>> Here's my attempt at a cleaned up patch series.
>> 
>> It doesn't include the delay modifications from your nand2.diff, as that
>> didn't actually work for me.  On my OpenRD is appears that the time tick is
>> started after the NAND initialisation, leading to infinite delays.  
>> 
> 
> I'm interested in hearing more about this.  I don't quite understand
> what you mean by "time tick is started after...".  The delay-related
> changes should completely remove all use of clocks or timing.  What it
> does instead is repeatedly issue "get status" commands to the chip until
> the chip says it's done with the previous operation and ready to
> continue.  
> 
> The big advantage is that a DELAY(1000) will always wait a millisecond,
> but modern nand chips are often ready to procede after just a few
> microseconds.  It really helped bulk data throughput.

Yes. tREAD on 54nm and newer chips can be as low as 35us, but typically you're looking at 70-100us on the 2x, 2y and 1x nm parts before the data is ready.  1000us is definitely too long to wait, and can only be considered very pessimal. The NAND chips will tell you when the data buffer can be read out was well by asking them for the status, and that needs no delays (not 100% true, but the delays are in the 10's or 100's of ns range and usually papered over by the NAND controller).

Warner