From patchwork Mon Jun 18 07:24:39 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Gerlando Falauto X-Patchwork-Id: 165407 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 9C6A5B72BE for ; Mon, 18 Jun 2012 17:26:44 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SgWKl-0002k8-1P; Mon, 18 Jun 2012 07:25:11 +0000 Received: from mail-de.keymile.com ([195.8.104.1]) by merlin.infradead.org with smtp (Exim 4.76 #1 (Red Hat Linux)) id 1SgWKg-0002jP-2i for linux-mtd@lists.infradead.org; Mon, 18 Jun 2012 07:25:07 +0000 Received: from mailrelay.de.keymile.net ([10.9.1.54]) by eSafe SMTP Relay 1340002952; Mon, 18 Jun 2012 09:25:02 +0200 Received: from chber1-10555x.ch.keymile.net (chber1-10555x.ch.keymile.net [172.31.40.82]) by mailrelay.de.keymile.net (8.12.2/8.12.2) with ESMTP id q5I7NvjQ028548; Mon, 18 Jun 2012 09:24:04 +0200 (MEST) From: Gerlando Falauto To: linux-mtd@lists.infradead.org Subject: [PATCH RFC 2/2] mtd: cfi_cmdset_0002: Micron M29EW bugfix "Resolving the Delay After Resume Issue" Date: Mon, 18 Jun 2012 09:24:39 +0200 Message-Id: <1340004279-26496-3-git-send-email-gerlando.falauto@keymile.com> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1340004279-26496-1-git-send-email-gerlando.falauto@keymile.com> References: <1340004279-26496-1-git-send-email-gerlando.falauto@keymile.com> MIME-Version: 1.0 X-ESAFE-STATUS: [srvhellgate.de.keymile.net] Mail clean X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [195.8.104.1 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Holger Brunck , Leo , Stefan Bigler , Gerlando Falauto 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 From TN-13-07: Patching the Linux Kernel and U-Boot for M29 Flash, page 22: Some revisions of the M29EW (for example, A1 and A2 step revisions) are affected by a problem that could cause a hang up when an ERASE SUSPEND command is issued after an ERASE RESUME operation without waiting for a minimum delay. The result is that once the ERASE seems to be completed (no bits are toggling), the contents of the Flash memory block on which the erase was ongoing could be inconsistent with the expected values (typically, the array value is stuck to the 0xC0, 0xC4, 0x80, or 0x84 values), causing a consequent failure of the ERASE operation. The occurrence of this issue could be high, especially when file system operations on the Flash are intensive. As a result, it is recommended that a patch be applied. Intensive file system operations can cause many calls to the garbage routine to free Flash space (also by erasing physical Flash blocks) and as a result, many consecutive SUSPEND and RESUME commands can occur. The problem disappears when a delay is inserted after the RESUME command by using the udelay () function available in Linux. The DELAY value must be tuned based on the customer’s platform. The maximum value that fixes the problem in all cases is 500us. But, in our experience, a delay of 30μs to 50μs is sufficient in most cases. We have chosen 500us because this latency is acceptable. Signed-off-by: Stefan Bigler Signed-off-by: Gerlando Falauto Cc: Holger Brunck Cc: Leo --- drivers/mtd/chips/cfi_cmdset_0002.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 72f6164..7fb24dc 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c @@ -767,6 +767,10 @@ static void put_chip(struct map_info *map, struct flchip *chip, unsigned long ad || ((cfi->device_type == CFI_DEVICETYPE_X16) && (cfi->id == 0x227e))) ) map_write(map, CMD(0xF0), chip->in_progress_block_addr); map_write(map, cfi->sector_erase_cmd, chip->in_progress_block_addr); + /* Resolving the Delay After Resume Issue see Micron TN-13-07 */ + /* Worstcase delay must be 500us but 30-50us should be ok as well + nbigls has choosen 500us because this latency is acceptable */ + udelay(500); chip->oldstate = FL_READY; chip->state = FL_ERASING; break;