devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Simon Guinot <sguinot-D+JDLXUtGQkAvxtiuMwx3w@public.gmane.org>,
	Willy Tarreau <w@1wt.eu>,
	Tawfik Bayouk <tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Thomas Petazzoni
	<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Gregory Clement
	<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Seif Mazareeb <seif-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH v2 3/4] mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
Date: Mon, 12 May 2014 16:18:41 -0300	[thread overview]
Message-ID: <20140512191841.GA3064@arch.cereza> (raw)
In-Reply-To: <20140512180104.GJ28907@ld-irv-0074>

Thanks for looking at this.

On 12 May 11:01 AM, Brian Norris wrote:
> On Fri, Mar 21, 2014 at 08:34:49AM -0300, Ezequiel Garcia wrote:
> > This commit adds support for the user to specify the ECC strength
> > and step size through the devicetree. We keep the previous behavior,
> > when there is no DT parameter provided.
> > 
> > Also, if there is an ONFI-specified minimum ECC strength requirement,
> > and the DT-specified ECC strength is weaker, print a warning and try to
> > select a strength compatible with the ONFI requirement.
> 
> Are you sure you want to override? That seems contrary to the idea of a
> DT property for specifying ECC. But maybe you have a good reason?
> 

Actually, on IRC discussions you enforced the idea that the kernel shouldn't
allow a weaker ECC strength than the datasheet (ONFI or ID table) specified.
Hence, following your request, the implementation considers such devicetree
setting as illegal and tries to find another one.

> If you'd rather just warn the user, it's possible we could move that to
> common code in nand_base.c.
> 

Now that you mention this, I think you're right: it's very stupid to try to
match an ECC scheme, different from the requested.

So, we either just warn the user (nosily) or we fail to probe the driver.
If you ask me, I'd say let's just WARN() and let the user take the blame.

> > 
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> >  drivers/mtd/nand/pxa3xx_nand.c                | 47 +++++++++++++++++++--------
> >  include/linux/platform_data/mtd-nand-pxa3xx.h |  3 ++
> >  2 files changed, 36 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
> > index cf7d757..cc13896 100644
> > --- a/drivers/mtd/nand/pxa3xx_nand.c
> > +++ b/drivers/mtd/nand/pxa3xx_nand.c
> > @@ -1344,8 +1344,30 @@ static int pxa3xx_nand_sensing(struct pxa3xx_nand_info *info)
> >  }
> >  
> >  static int pxa_ecc_init(struct pxa3xx_nand_info *info,
> > -			struct nand_ecc_ctrl *ecc, int strength, int page_size)
> > +			struct nand_chip *chip,
> > +			struct pxa3xx_nand_platform_data *pdata,
> > +			unsigned int page_size)
> >  {
> > +	struct nand_ecc_ctrl *ecc = &chip->ecc;
> > +	unsigned int strength, onfi_strength;
> > +
> > +	/* We need to normalize the ECC strengths, in order to compare them. */
> > +	strength = (pdata->ecc_strength * 512) / pdata->ecc_step_size;
> > +	onfi_strength = (chip->ecc_strength_ds * 512) / chip->ecc_step_ds;
> 
> This is not necessarily an "ONFI" property; we also have the full-ID
> table in which a minimum ECC strength can be specified. Maybe you can
> match the existing naming with "strength" and "strength_ds" (for
> "datasheet").
>

Right.
 
> > +
> > +	/*
> > +	 * The user requested ECC strength cannot be weaker than the ONFI
> > +	 * minimum specified ECC strength.
> > +	 */
> > +	if (strength && strength < onfi_strength) {
> > +		dev_warn(&info->pdev->dev,
> > +			 "requested ECC strength is too weak\n");
> > +		strength = onfi_strength;
> > +	}
> > +
> > +	if (!strength)
> > +		strength = onfi_strength ? onfi_strength : 1;
> > +
> 
> I'm also not sure your "normalization" is generally correct. You can't
> really normalize correction strengths to get a fully valid comparison.
> Remember, 4-bit/2048B correction is not the same as 1-bit/512B
> correction; it is at least as strong, yes.

So far so good.

> But then, the reverse is
> *not* a good comparison. So your code might say that a flash which
> requires 4-bit/2KB can be satisfied by 1-bit/512B. (These numbers may
> not be seen in practice, but you get my point, right?)
> 

Ah... missed the reverse.

> By my understanding, a correct comparison requires two parts, which I've
> summarized like this in my own code:
> 
>         /*
>          * Does the given configuration meet the requirements?
>          *
>          * If our configuration corrects A bits per B bytes and the minimum
>          * required correction level is X bits per Y bytes, then we must ensure
>          * both of the following are true:
>          *
>          * (1) A / B >= X / Y
>          * (2) A >= X
>          *
>          * Requirement (1) ensures we can correct for the required bitflip
>          * density.
>          * Requirement (2) ensures we can correct even when all bitflips are
>          * clumped in the same sector.
>          */
> 
> I think you are doing (1), but not (2).
> 

Great catch! I missed this detail entirely.

> >  	if (strength == 1 && page_size == 2048) {
> >  		info->chunk_size = 2048;
> >  		info->spare_size = 40;
> > @@ -1375,7 +1397,6 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
> >  		ecc->size = info->chunk_size;
> >  		ecc->layout = &ecc_layout_2KB_bch4bit;
> >  		ecc->strength = 16;
> > -		return 1;
> >  
> >  	} else if (strength == 4 && page_size == 4096) {
> >  		info->ecc_bch = 1;
> > @@ -1424,7 +1445,6 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
> >  	uint32_t id = -1;
> >  	uint64_t chipsize;
> >  	int i, ret, num;
> > -	uint16_t ecc_strength, ecc_step;
> >  
> >  	if (pdata->keep_config && !pxa3xx_nand_detect_config(info))
> >  		goto KEEP_CONFIG;
> > @@ -1519,17 +1539,8 @@ KEEP_CONFIG:
> >  		}
> >  	}
> >  
> > -	ecc_strength = chip->ecc_strength_ds;
> > -	ecc_step = chip->ecc_step_ds;
> > -
> > -	/* Set default ECC strength requirements on non-ONFI devices */
> > -	if (ecc_strength < 1 && ecc_step < 1) {
> > -		ecc_strength = 1;
> > -		ecc_step = 512;
> > -	}
> > -
> > -	ret = pxa_ecc_init(info, &chip->ecc, (ecc_strength * 512) / ecc_step,
> > -			   mtd->writesize);
> > +	/* Selects an ECC and fills pxa3xx_nand_info and nand_chip */
> > +	ret = pxa_ecc_init(info, chip, pdata, mtd->writesize);
> >  	if (ret)
> >  		return ret;
> >  
> > @@ -1729,6 +1740,14 @@ static int pxa3xx_nand_probe_dt(struct platform_device *pdev)
> >  	of_property_read_u32(np, "num-cs", &pdata->num_cs);
> >  	pdata->flash_bbt = of_get_nand_on_flash_bbt(np);
> >  
> > +	pdata->ecc_strength = of_get_nand_ecc_strength(np);
> > +	if (pdata->ecc_strength < 0)
> 
> ecc_strength is unsigned, so this error check doesn't work. Maybe you
> want a local 'int ret' to temporarily stash the return value?
> 

Correct.

I'll prepare new patchset.

Thanks!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-05-12 19:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21 11:34 [PATCH v2 0/4] Allow to specify an ECC scheme through DT Ezequiel Garcia
     [not found] ` <1395401690-25221-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-03-21 11:34   ` [PATCH v2 1/4] mtd: nand: pxa3xx: Normalize ECC strength for ECC scheme selection Ezequiel Garcia
2014-03-21 11:34   ` [PATCH v2 2/4] mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling Ezequiel Garcia
2014-03-21 11:34   ` [PATCH v2 3/4] mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding Ezequiel Garcia
     [not found]     ` <1395401690-25221-4-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-05-12 18:01       ` Brian Norris
2014-05-12 19:18         ` Ezequiel Garcia [this message]
     [not found]           ` <20140512191841.GA3064-nAQHv47ARr+vIlHkl8J1cg@public.gmane.org>
2014-05-13 23:37             ` Brian Norris
2014-03-21 11:34   ` [PATCH v2 4/4] mtd: nand: pxa3xx: Add supported ECC strength and step size to the DT binding Ezequiel Garcia
2014-04-01 10:04 ` [PATCH v2 0/4] Allow to specify an ECC scheme through DT Simon Guinot
     [not found]   ` <20140401100417.GI27979-tZfvYpCFA3RN6yImKYG91Q@public.gmane.org>
2014-04-03 15:19     ` Ezequiel Garcia
     [not found]       ` <20140403151941.GA21114-nAQHv47ARr+vIlHkl8J1cg@public.gmane.org>
2014-04-14 14:56         ` Ezequiel Garcia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140512191841.GA3064@arch.cereza \
    --to=ezequiel.garcia-wi1+55scjutkeb57/3fjtnbpr1lh4cv8@public.gmane.org \
    --cc=alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    --cc=linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=seif-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=sguinot-D+JDLXUtGQkAvxtiuMwx3w@public.gmane.org \
    --cc=tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).