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))
--
balbi
Attachment:
signature.asc
Description: Digital signature
