From owner-freebsd-embedded@FreeBSD.ORG Fri Nov 15 18:22:50 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8B3A9B4 for ; Fri, 15 Nov 2013 18:22:50 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8D622C4F for ; Fri, 15 Nov 2013 18:22:50 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id at1so5301085iec.16 for ; Fri, 15 Nov 2013 10:22:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=v7gmHGniT2YLb2/hYUiPAOW7DEHLZN3TECJ9i7T5bX8=; b=iVUT/4yXIDiTZtFIabf2tXIPBVRljkBET1d/BC1xpmymMq5VK9uUqfnQcXp6EZzAS/ 56q18zQjdssXyU5oU6xN7Bw0E0f5fToC+byXFuShnsi0li82tCu0Rul8HcybHaZDsJJR Vh6JQiApfiR7tcB12rj6r/Q1MkX7h4P1hKKYnr8eP+4HDO6ZW7PxQe+EQ6+quu/zfbYW PL14kzamoFpBPrEoTgoyXklHtjKBLujYsSXwV8oHJKaUOvzrdxv6/yAJXvMeerQ7PD1H +EaZEnuzDqAHQ8Sqsm+JZVh1W8jucII4/IchnXDwWe8drY6LhHeHQ94B4Kn1LgIysxak 1CYg== X-Gm-Message-State: ALoCoQkijyMmG+6M0FqM0B8Cn6UsXgXzt5CTBWnVUe3nHssBXEUKIorRl2uBpHxvAuQh+OuPxPqL X-Received: by 10.50.73.74 with SMTP id j10mr5351489igv.50.1384539764563; Fri, 15 Nov 2013 10:22:44 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id w4sm4482047igb.5.2013.11.15.10.22.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 10:22:44 -0800 (PST) Sender: Warner Losh Subject: Re: Incorrect struct onfi_params definition Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1384537153.31172.398.camel@revolution.hippie.lan> Date: Fri, 15 Nov 2013 11:22:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73F6EE79-C4CB-4831-8DA3-6EE70931C0DA@bsdimp.com> References: <1383782353.31172.183.camel@revolution.hippie.lan> <1384381960-98851-1-git-send-email-kristof@sigsegv.be> <1384537153.31172.398.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: Grzegorz Bernacki , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 18:22:50 -0000 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