From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965063AbaDIVLd (ORCPT ); Wed, 9 Apr 2014 17:11:33 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:59098 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933885AbaDIVLb (ORCPT ); Wed, 9 Apr 2014 17:11:31 -0400 X-Auth-Info: FIXyn6pFwogzuxecWvDOGPUItmTEJL7M70HGN+c34Ls= From: Marek Vasut To: Graham Moore Subject: Re: [PATCH] Add support for flag status register on Micron chips Date: Wed, 9 Apr 2014 20:31:20 +0200 User-Agent: KMail/1.13.7 (Linux/3.13-trunk-amd64; KDE/4.11.3; x86_64; ; ) Cc: Gerhard Sittig , "grmoore@altera.com" , David Woodhouse , Brian Norris , Artem Bityutskiy , Sourav Poddar , Sascha Hauer , Geert Uytterhoeven , Jingoo Han , Insop Song , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Alan Tull , Dinh Nguyen , Yves Vandervennet References: <1396973570-13995-1-git-send-email-grmoore@altera.com> <20140409110933.GS11339@book.gsilab.sittig.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201404092031.20439.marex@denx.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, April 09, 2014 at 08:14:49 PM, Graham Moore wrote: > On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig wrote: > > On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote: > >> On Tuesday, April 08, 2014 at 06:12:49 PM, grmoore@altera.com wrote: > >> > From: Graham Moore > >> > > >> > This is a slightly different version of the patch that Insop Song > >> > submitted > >> > (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). > >> > > >> > I talked to Insop, and he agreed I should submit this patch as a > >> > follow-on to his. > >> > > >> > This patch uses a flag in the m25p_ids[] array to determine which > >> > chips need to use the FSR (Flag Status Register). > >> > > >> > Rationale for using the FSR: > >> > > >> > The Micron data sheets say we have to do this, at least for the > >> > multi-die 512M and 1G parts (n25q512 and n25q00). In practice, if we > >> > don't check the FSR for program/erase status, and we rely solely on > >> > the status register (SR), then we get corrupted data in the flash. > > [...] > > >> > Micron told us (Altera) that for multi-die chips based on the 65nm > >> > 256MB die, we need to check the SR first, then check the FSR, which > >> > is why the wait_for_fsr_ready function does that. Future chips based > >> > on 45 nm 512MB die will use the FSR only. > > > > This sounds to me similar to polling the NAND's R/B pin until the > > operation has completed, to then fetch the STATUS byte to > > determine the execution's result. Does this sound plausible? > > For NOR, do you poll for the "busy" condition to deassert, and > > check for success then? > > Sounds plausible to me. We poll the SR until not busy, then poll the > FSR until it's not busy. Success is when FSR busy is deasserted > within the timeout. > > Micron said we have to read the FSR "at least once", so we don't > read it once for every die or anything like that. I ran a quick > test, and for both the 2-die and 4-die parts, the FSR shows not busy > on the first read after SR not busy. I'd love to know how this FSR-not-busy is exactly related to SR-not-busy, but I guess only Micron can tell :-/ Best regards, Marek Vasut