From noodles@earth.li Wed Apr 01 22:54:14 2009 Received: from limegreen.tangerine.org.uk ([217.147.81.4]) by stoneboat.aleph1.co.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lp8Ns-000632-QO for balloon@balloonboard.org; Wed, 01 Apr 2009 22:54:14 +0100 Received: from [89.195.130.171] (helo=shirataki.orange) by limegreen.tangerine.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lp8Np-0004q4-Ea; Wed, 01 Apr 2009 22:54:07 +0100 Received: from noodles by shirataki.orange with local (Exim 4.69) (envelope-from ) id 1Lp8Nj-0001Sb-CW; Wed, 01 Apr 2009 22:53:59 +0100 Date: Wed, 1 Apr 2009 22:53:59 +0100 From: Jonathan McDowell To: Chris Jones Message-ID: <20090401215359.GA5306@earth.li> References: <41e5b4c20903260947wc4831d1l1c38ef904c52961f@mail.gmail.com> <20090326165524.GD30715@earth.li> <41e5b4c20903261041o1e50402aq5a8840d1a66e7196@mail.gmail.com> <20090327093121.GH30715@earth.li> <49D149D0.1020806@martin-jones.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D149D0.1020806@martin-jones.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: 217.147.81.4 X-SA-Exim-Mail-From: noodles@earth.li X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Cc: balloon@balloonboard.org Subject: Re: [Balloon] Bad blocks caused by expiring mtd status poll loop in 2.6.29-rc7 X-BeenThere: balloon@balloonboard.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Balloon List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:54:15 -0000 On Mon, Mar 30, 2009 at 11:38:08PM +0100, Chris Jones wrote: > Jonathan McDowell wrote: > > On Thu, Mar 26, 2009 at 10:31:35PM +0000, Chris Jones wrote: > > > >> - are we currently trying to run NAND bus cycles too fast? This is > >> moderately unlikely since we slowed it down hugely to make the minipug > >> LCDs work over Samosa, unless Jim was running an old bootldr. > > > > As Jim has said, he wasn't running the new bootldr, so it's quite > > possible that would have sorted things out. > > I had a look at the data sheet for the NAND chips and they seem to be > able to cope with nRE and nWE pulse lengths of 15ns, compared with the > 200+ns that the minipugs need, so I doubt we're at risk of running the > bus too fast with them! Pass. The cpufreq stuff does seem to be causing some weird issues in general though. > >> - do we want to observe NAND_RNB in hardware (thus locking up the bus > >> while the NAND gets its act together) or in software? I'm not even > >> sure that this is an appropriate question to ask, but someone else may > >> have a quick answer before I go and grub around in data sheets and > >> kernel source. > > > > Hooking up support for a NAND ready line in the kernel mtd driver is > > easy; I hadn't realised we weren't already doing that. I can't actually > > see where NAND_RNB gets mapped to for reading though? > > Again, my look at the data sheet shows that NAND_RNB really means 'this > chip is doing something time-consuming internally' rather than 'hold the > bus while I sort my registers out', Yes, that's my understanding of how it should be used. > so it should be observed in software, not VLIO hardware. > At the moment, NAND_RNB goes precisely nowhere in the hardware, > according to the VHDL I'm looking at. We can fix that. It appears that > the CPLD/FPGA doesn't have a readable control register, so we'll have to > give it one. This may be an opportunity to make some of the other > control signals (NAND/IO parking and so on) read-back-able, too, though > at the risk of introducing firmware version/kernel version nightmares. As I say, making the kernel mtd stuff use a NAND ready line is easy; we just need to provide a dev_ready function that checks it and then the MTD code will use that function rather than a delay loop. J.