diff mbox

[v7,1/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes

Message ID 20131011115327.GA25706@radagast
State New, archived
Headers show

Commit Message

Felipe Balbi Oct. 11, 2013, 11:53 a.m. UTC 
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 mbox

Patch

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))