Date: Fri, 15 Nov 2013 11:22:42 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Grzegorz Bernacki <gber@FreeBSD.org>, freebsd-embedded@FreeBSD.org Subject: Re: Incorrect struct onfi_params definition Message-ID: <73F6EE79-C4CB-4831-8DA3-6EE70931C0DA@bsdimp.com> In-Reply-To: <1384537153.31172.398.camel@revolution.hippie.lan> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> <1384537153.31172.398.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 15, 2013, at 10:39 AM, Ian Lepore wrote: > On Wed, 2013-11-13 at 23:32 +0100, kristof@sigsegv.be wrote: >> Hi Ian, >>=20 >> Here's my attempt at a cleaned up patch series. >>=20 >> 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. =20= >>=20 >=20 > 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. =20 >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?73F6EE79-C4CB-4831-8DA3-6EE70931C0DA>