From patchwork Fri Oct 11 11:53:27 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 282718 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from casper.infradead.org (unknown [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 5BBE82C008C for ; Fri, 11 Oct 2013 22:54:37 +1100 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VUbIV-0007mT-Dd; Fri, 11 Oct 2013 11:54:23 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VUbIT-0006ME-Le; Fri, 11 Oct 2013 11:54:21 +0000 Received: from comal.ext.ti.com ([198.47.26.152]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VUbIR-0006LC-Ca for linux-mtd@lists.infradead.org; Fri, 11 Oct 2013 11:54:19 +0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id r9BBrdZM031981; Fri, 11 Oct 2013 06:53:39 -0500 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id r9BBrdZh025995; Fri, 11 Oct 2013 06:53:39 -0500 Received: from dlep33.itg.ti.com (157.170.170.75) by DFLE72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.2.342.3; Fri, 11 Oct 2013 06:53:39 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id r9BBrdlO002648; Fri, 11 Oct 2013 06:53:39 -0500 Date: Fri, 11 Oct 2013 06:53:27 -0500 From: Felipe Balbi To: "Gupta, Pekon" Subject: Re: [PATCH v7 1/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes Message-ID: <20131011115327.GA25706@radagast> References: <1380916188-24206-1-git-send-email-pekon@ti.com> <1380916188-24206-2-git-send-email-pekon@ti.com> <20131007112728.GA15365@e106331-lin.cambridge.arm.com> <20980858CB6D3A4BAE95CA194937D5E73EA1F3DC@DBDE04.ent.ti.com> <20980858CB6D3A4BAE95CA194937D5E73EA2122E@DBDE04.ent.ti.com> MIME-Version: 1.0 In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA2122E@DBDE04.ent.ti.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131011_075419_509796_43026707 X-CRM114-Status: GOOD ( 27.58 ) X-Spam-Score: -7.1 (-------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-7.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [198.47.26.152 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Mark Rutland , "devicetree@vger.kernel.org" , "computersforpeace@gmail.com" , Pawel Moll , "arnd@arndb.de" , "dedekind1@gmail.com" , "tony@atomide.com" , "ijc+devicetree@hellion.org.uk" , "avinashphilipk@gmail.com" , "Balbi, Felipe" , "olof@lixom.net" , "robherring2@gmail.com" , "bcousson@baylibre.com" , "swarren@wwwdotorg.org" , "linux-mtd@lists.infradead.org" , Andrew Morton , "linux-omap@vger.kernel.org" , "dwmw2@infradead.org" X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: balbi@ti.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Hi Pekon, On Fri, Oct 11, 2013 at 05:17:48AM -0500, Gupta, Pekon wrote: > > > If I have my NAND formatted with one of the existing ECC schemes (e.g. > > > OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new > > > OMAP_ECC_HAM1_CODE_HW scheme? > > > > > > Are they all compatible? > > > > > Yes, they all are 1-bit hamming code, the only difference between > > xx_Default and xx_HW was who was doing the ECC calculation. > > For xx_DEFAULT: ECC calculation was done on CPU via s/w library > > For xx_HW: ECC calculation was done by in-build h/w engine. > > So, all HAMMING_xx can be replaced by HAM1_HW. > > > > [snip] > > > > > > @@ -1342,9 +1342,7 @@ static void __maybe_unused > > > gpmc_read_timings_dt(struct device_node *np, > > > > #ifdef CONFIG_MTD_NAND > > > > > > > > static const char * const nand_ecc_opts[] = { > > > > - [OMAP_ECC_HAMMING_CODE_DEFAULT] = "sw", > > > > - [OMAP_ECC_HAMMING_CODE_HW] = "hw", > > > > - [OMAP_ECC_HAMMING_CODE_HW_ROMCODE] = "hw- > > > romcode", > > > > + [OMAP_ECC_HAM1_CODE_HW] = "ham1", > > > > [OMAP_ECC_BCH4_CODE_HW] = "bch4", > > > > [OMAP_ECC_BCH8_CODE_HW] = "bch8", > > > > > > Won't this break existing dts which have "sw", "hw", or "hw-romcode"? > > > > > > Someone may try to use a new kernel with an old dt, and we marked them > > > as deprecated, not removed. > > > > > HAMMING_xx ECC scheme was used only on legacy platforms, when > > BCH8 was not available, I have not seen anyone using this scheme > > *from mainline kernel* from quite a long time. So, it's safe to remove them. > > > > This is what was concluded as per below email. > > http://lists.infradead.org/pipermail/linux-mtd/2013-September/048876.html > > > > This patch-series and its follow-on series has already missed many merge > windows, And the above discussion has reached a stalled state (infinite loop) > where, I cannot revert some DT binding updates to and fro to keep all legacy > DT bindings backward compatible forever. > However, I can assure that these DT updates make binding stable for long-term. > > So now it's your discretion to whether to accept or leave following 2 series: > > http://lists.infradead.org/pipermail/linux-mtd/2013-October/048983.html > > http://lists.infradead.org/pipermail/linux-mtd/2013-October/049008.html > > > AFAIK no-one is using Hamming based ecc-scheme on OMAP platforms > *from mainline kernel*. So this DT update actually does not affect users > I know of. Rather these patch series was intended for long term scalability > and clean-up so that more OMAP users migrate to mainline kernel easily. wouldn't something like below maintain backwards compatibility ? diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 579697a..f33ffe0 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1383,6 +1383,10 @@ static int gpmc_probe_nand_child(struct platform_device *pdev, if (!strcasecmp(s, nand_ecc_opts[val])) { gpmc_nand_data->ecc_opt = val; break; + } else if (!strcasecmp(s, "sw") || + !strcasecmp(s, "hw") || + !strcasecmp(s, "hw-romcode")) { + gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_HW; } if (!of_property_read_string(child, "ti,nand-xfer-type", &s))