From patchwork Thu Mar 1 14:57:14 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paul Parsons X-Patchwork-Id: 144061 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 0EFC11007D5 for ; Fri, 2 Mar 2012 01:58:39 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1S37RZ-0000uJ-Vw; Thu, 01 Mar 2012 14:57:22 +0000 Received: from nm14.bullet.mail.ird.yahoo.com ([77.238.189.67]) by merlin.infradead.org with smtp (Exim 4.76 #1 (Red Hat Linux)) id 1S37RT-0000sv-Q8 for linux-mtd@lists.infradead.org; Thu, 01 Mar 2012 14:57:19 +0000 Received: from [77.238.189.230] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 01 Mar 2012 14:57:14 -0000 Received: from [212.82.108.134] by tm11.bullet.mail.ird.yahoo.com with NNFMP; 01 Mar 2012 14:57:14 -0000 Received: from [127.0.0.1] by omp1039.mail.ird.yahoo.com with NNFMP; 01 Mar 2012 14:57:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 326895.95405.bm@omp1039.mail.ird.yahoo.com Received: (qmail 15243 invoked by uid 60001); 1 Mar 2012 14:57:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330613834; bh=OP4dPlUM5JjWJ/fJXUFGa+pVbGMkTNCBeCWkdDABoic=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YC/59B8C8qIfzxMlB+f2UfCy/Ww+eJe1wKDXE0t4P1SviOvFpLV+Dfnkf2tJwgBnkeI+k+adTd3pWWlACQAZ1ToU330IkLtP5BlPSJSz2MpsGRP86l1MaK2MYu5GLwZZbfbFtTQhkjwkylqnKvyA0Ip+GIcb6W7zyQ1qC0Uj3a8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WycFB1wSlNHdrW4G872O6grVSP8Bgzo/X/9Idqxvw+JQ75tJC770auuzIideSievwz805ClXjyw3b4VBzNm4+RgiEIxFdvYBAgRO71O0CLyq9scMXb6s8WG0vIL2oxvDbY1s2fxk6YuNfNR3IAh+9rPc8TnVX2ZkkrqfvGSEIHw=; X-YMail-OSG: YambVCQVM1kW.zIxzbzhoDr1c5vPYwgu4ff9xtxzXbicNkd JZcFdjkzWys3thocs0HUKXWtzuebT8t5g4GvnnpW.M1N9m0MlJRoUp_kdSCU e6TdAphouTV82trz.T72s3m5a70VhpBqKxqEdz1Il8a0YErsAdfWEG7TR7Is ywPHpibaVzBCMq5J6vps2wSPrwYDirysWW2N_gXhyGnAdWpiu1otRroCT.Vq .im2p5nxoKlMA2ckps6bp.n.51vgIblxxgH18B9k32VSncpo7tzSMmB09GL2 qtxS9GnDEVO4qiBEqRNWdx3xJd4m8Vdx8XIr.hC3R6IB7P0npwMuCpX_cQDo TpG07iTG32eYlltInyhLyZ1dnWBXRiTK8r.S56gRNdUowa5lsbTiAzarG3T. RmuK2YCHygPsDwlpPbr6C6AfeSrhjuMB_go_I862eonLvWcAPaxOfumkr1s3 Rh0Z7 Received: from [87.114.7.88] by web29010.mail.ird.yahoo.com via HTTP; Thu, 01 Mar 2012 14:57:14 GMT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1330613834.5242.YahooMailClassic@web29010.mail.ird.yahoo.com> Date: Thu, 1 Mar 2012 14:57:14 +0000 (GMT) From: Paul Parsons Subject: Re: [PATCH] mtd: cfi: Wait for Block Erase operation to finish To: Joakim Tjernlund In-Reply-To: MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.0 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (lost.distance[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [77.238.189.67 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: dwmw2@infradead.org, linux-mtd@lists.infradead.org, philipp.zabel@gmail.com X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org --- On Wed, 29/2/12, Joakim Tjernlund wrote: > This looks like a erase resume problem, cfi driver issues a > resume command but the > chip fails or is slow to respond. I remember someone having > a similar problem > some time ago. Don't think we got to bottom of it though, > look for subject: >   Numonyx NOR and chip->mutex bug? Yes, that Numonyx NOR problem seems to be the same as mine. > Try adding extra read status cmds around resume, check if > SR.6 is cleared too. OK, I think I've made some progress here. The status transitions around the Erase Resume are as follows: [ 58.702774] 108: PUTC: 0: status=0x00c000c0 // Before CMD(0xd0) [ 58.702792] 108: PUTC: 1: status=0x00400040 // After CMD(0xd0),CMD(0x70) [ 58.702808] 108: PUTC: 2: status=0x00000000 // + cfi_udelay(1) So SR.7 transitions from 1 to 0 after CMD(0xd0), and some time later SR.6 transitions from 1 to 0. So the effects of Erase Resume are not immediate. Thus it seemed a good idea to wait for these bits to settle: This patch adds a wait after Erase Resume, just like the existing one after Erase Suspend (but without the timeout). I added the FL_ERASE_RESUMING state to perform the same function as the FL_ERASE_SUSPENDING state: to stop anyone else touching it. When I tried this patch in place of my previous one I found it too fixed my problem. That's not a surprise because it does the same thing, it waits for SR.6 to clear, but at an earlier point. Unlike my previous patch, this patch leaves SR.7 and SR.6 in a consistent state before put_chip() returns (and indeed before the call to wake_up(&chip->wq) at the bottom of put_chip()). What I don't know is why not waiting for SR.7 and SR.6 to settle after Erase Resume can then break UBI, in particular provoking the "block erase error: (bad VPP)" messages I was seeing earlier. diff -upr clean-3.3-rc5/drivers/mtd/chips/cfi_cmdset_0001.c linux-3.3-rc5/drivers/mtd/chips/cfi_cmdset_0001.c --- clean-3.3-rc5/drivers/mtd/chips/cfi_cmdset_0001.c 2012-02-25 20:18:16.000000000 +0000 +++ linux-3.3-rc5/drivers/mtd/chips/cfi_cmdset_0001.c 2012-03-01 13:44:49.529371920 +0000 @@ -956,6 +956,7 @@ static int get_chip(struct map_info *map static void put_chip(struct map_info *map, struct flchip *chip, unsigned long adr) { struct cfi_private *cfi = map->fldrv_priv; + map_word status, status_40 = CMD(0x40), status_00 = CMD(0x00); if (chip->priv) { struct flchip_shared *shared = chip->priv; @@ -1006,6 +1007,15 @@ static void put_chip(struct map_info *ma map_write(map, CMD(0xd0), adr); map_write(map, CMD(0x70), adr); chip->oldstate = FL_READY; + chip->state = FL_ERASE_RESUMING; + for (;;) { + status = map_read(map, adr); + if (map_word_andequal(map, status, status_40, status_00)) + break; + mutex_unlock(&chip->mutex); + cfi_udelay(1); + mutex_lock(&chip->mutex); + } chip->state = FL_ERASING; break; diff -upr clean-3.3-rc5/include/linux/mtd/flashchip.h linux-3.3-rc5/include/linux/mtd/flashchip.h --- clean-3.3-rc5/include/linux/mtd/flashchip.h 2012-02-25 20:18:16.000000000 +0000 +++ linux-3.3-rc5/include/linux/mtd/flashchip.h 2012-03-01 13:41:48.288232532 +0000 @@ -36,6 +36,7 @@ typedef enum { FL_ERASING, FL_ERASE_SUSPENDING, FL_ERASE_SUSPENDED, + FL_ERASE_RESUMING, FL_WRITING, FL_WRITING_TO_BUFFER, FL_OTP_WRITE,