gpmi-mtd ecc regression
Brian Norris
computersforpeace at gmail.com
Mon Oct 21 00:21:24 PDT 2013
On Sun, Oct 20, 2013 at 8:30 PM, Huang Shijie <b32955 at freescale.com> wrote:
> 于 2013年10月19日 01:03, Tim Harvey 写道:
>>
>> The patch you made to obtain ECC info from the chip
>>
>> (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/nand/gpmi-nand?id=2febcdf84b75aae627c61f0a5bf531a69299966c)
>> has caused a regression for an i.MX6 board I'm working with that uses
>> NAND and ubifs.
...
> I am in an embarrass state now:
> [1] we can support the jffs2, when we use the set_geometry_by_ecc_info() to
> set the NAND layout.
>
> [2] if we still use the legacy_set_geometry() to set the NAND layout, we can
> not support the jffs2 for GPMI.
>
>
> When i submitted the gpmi to the kernel, the mtd code can not provide me the
> ECC info. I had to use all the OOB
> with legacy_set_geometry(). After i submitted several patches for mtd, it
> can provide us the ECC info now, so i switch
> to use the set_geometry_by_ecc_info().
>
> it's easy to fix your problem with a patch like this:
> -----------------------------------------------------------------------------------------------------------------
>
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand
> index 5a1bbc7..8eeead6 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -352,7 +352,8 @@ static int legacy_set_geometry(struct gpmi_nand_data
> *this)
>
> int common_nfc_set_geometry(struct gpmi_nand_data *this)
> {
> - return set_geometry_by_ecc_info(this) ? 0 :
> legacy_set_geometry(this);
> + return (legacy_set_geometry(this) == 0) ? 0 :
> + set_geometry_by_ecc_info(this);
> }
>
> struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
>
>
> -----------------------------------------------------------------------------------------------------------------
So you really have two wholly incompatible layout methods, one which
targeted using the maximum ECC strength that fits and one which
targets the minimum required ECC strength? It seems that you can only
use a new ECC/geometry if the user prompts you to do so (via device
tree, for instance). Doing otherwise is bound to create regressions
like this.
> But after apply this patch, the gpmi may can not support the JFFS2 any more.
Well, we do prioritize "no regressions", rather than new features. So
we may have to do this until a proper solution can be formed.
Brian
More information about the linux-mtd
mailing list