All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abhishek Sahu <absahu@codeaurora.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org, Andy Gross <andy.gross@linaro.org>,
	Archit Taneja <architt@codeaurora.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>
Subject: Re: [PATCH v3 01/16] mtd: rawnand: helper function for setting up ECC configuration
Date: Mon, 11 Jun 2018 14:46:00 +0530	[thread overview]
Message-ID: <7cf002e3d7ebd46476554477dd92716f@codeaurora.org> (raw)
In-Reply-To: <20180607143759.361edb3f@xps13>

On 2018-06-07 18:07, Miquel Raynal wrote:
> Hi Abhishek,
> 
> On Mon, 28 May 2018 11:16:29 +0530, Abhishek Sahu
> <absahu@codeaurora.org> wrote:
> 
>> On 2018-05-26 14:12, Miquel Raynal wrote:
>> > Hi Abhishek,
>> > > On Fri, 25 May 2018 17:51:29 +0530, Abhishek Sahu
>> > <absahu@codeaurora.org> wrote:
>> > >> commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
>> >> match, maximize ECC settings") provides generic helpers which
>> >> drivers can use for setting up ECC parameters.
>> >> >> Since same board can have different ECC strength nand chips so
>> >> following is the logic for setting up ECC strength and ECC step
>> >> size, which can be used by most of the drivers.
>> >> >> 1. If both ECC step size and ECC strength are already set
>> >>    (usually by DT) then just check whether this setting
>> >>    is supported by NAND controller.
>> >> 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
>> >>    supported by NAND controller.
>> >> 3. Otherwise, try to match the ECC step size and ECC strength closest
>> >>    to the chip's requirement. If available OOB size can't fit the chip
>> >>    requirement then select maximum ECC strength which can be fit with
>> >>    available OOB size.
>> >> >> This patch introduces nand_ecc_choose_conf function which calls the
>> >> required helper functions for the above logic. The drivers can use
>> >> this single function instead of calling the 3 helper functions
>> >> individually.
>> >> >> CC: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>> >> ---
>> >> * Changes from v2:
>> >> >>   1. Renamed function to nand_ecc_choose_conf.
>> >>   2. Minor code reorganization to remove warning and 2 function calls
>> >>      for nand_maximize_ecc.
>> >> >> * Changes from v1:
>> >>   NEW PATCH
>> >> >>  drivers/mtd/nand/raw/nand_base.c | 42 >> ++++++++++++++++++++++++++++++++++++++++
>> >>  drivers/mtd/nand/raw/nand_base.c | 31 +++++++++++++++++++++++++++++++
>> >>  include/linux/mtd/rawnand.h      |  3 +++
>> >>  2 files changed, 34 insertions(+)
>> >> >> diff --git a/drivers/mtd/nand/raw/nand_base.c >> b/drivers/mtd/nand/raw/nand_base.c
>> >> index 72f3a89..e52019d 100644
>> >> --- a/drivers/mtd/nand/raw/nand_base.c
>> >> +++ b/drivers/mtd/nand/raw/nand_base.c
>> >> @@ -6249,6 +6249,37 @@ int nand_maximize_ecc(struct nand_chip *chip,
>> >>  }
>> >>  EXPORT_SYMBOL_GPL(nand_maximize_ecc);
>> >> >> +/**
>> >> + * nand_ecc_choose_conf - Set the ECC strength and ECC step size
>> >> + * @chip: nand chip info structure
>> >> + * @caps: ECC engine caps info structure
>> >> + * @oobavail: OOB size that the ECC engine can use
>> >> + *
>> >> + * Choose the ECC configuration according to following logic
>> >> + *
>> >> + * 1. If both ECC step size and ECC strength are already set (usually >> by DT)
>> >> + *    then check if it is supported by this controller.
>> >> + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
>> >> + * 3. Otherwise, try to match the ECC step size and ECC strength >> closest
>> >> + *    to the chip's requirement. If available OOB size can't fit the >> chip
>> >> + *    requirement then fallback to the maximum ECC step size and ECC >> strength.
>> >> + *
>> >> + * On success, the chosen ECC settings are set.
>> >> + */
>> >> +int nand_ecc_choose_conf(struct nand_chip *chip,
>> >> +			 const struct nand_ecc_caps *caps, int oobavail)
>> >> +{
>> >> +	if (chip->ecc.size && chip->ecc.strength)
>> >> +		return nand_check_ecc_caps(chip, caps, oobavail);
>> >> +
>> >> +	if (!(chip->ecc.options & NAND_ECC_MAXIMIZE) &&
>> >> +	    !nand_match_ecc_req(chip, caps, oobavail))
>> >> +		return 0;
>> >> +
>> >> +	return nand_maximize_ecc(chip, caps, oobavail);
>> > > I personally don't mind if nand_maximize_ecc() is called twice in
>> > the function if it clarifies the logic. Maybe the following will be
>> > more clear for the user?
>> 
>>   Thanks Miquel.
>>   Both the implementations are fine.
>>   The above implementation (which was in Denali NAND driver) code was 
>> also
>>   clear. We can go for any of these implementation.
>> 
>>   Shall I update this ?
> 
> Yes, please :)
> 

  Thanks Miquel for confirming.
  I will update accordingly.

  Also, one more question.

  Shall I make other functions (nand_check_ecc_caps, nand_maximize_ecc
  and nand_match_ecc_req) static.  Since currently,
  Denali NAND driver was only using these functions.

  And Now, this nand_ecc_choose_conf will be help
  in all the cases.

  For nand_check_ecc_caps: call nand_ecc_choose_conf with
                            chip->ecc.size && chip->ecc.strength

  For nand_maximize_ecc: call nand_ecc_choose_conf with
                         NAND_ECC_MAXIMIZE

  For other cases, nand_match_ecc_req will be called.

  So we will have one external function which will be
  easy to maintain in future.

  Thanks,
  Abhishek

>> 
>> > > 	if (chip->ecc.size && chip->ecc.strength)
>> > 		return nand_check_ecc_caps(chip, caps, oobavail);
>> > > 	if (chip->ecc.options & NAND_ECC_MAXIMIZE)
>> > 		return nand_maximize_ecc(chip, caps, oobavail);
>> > > 	if (!nand_match_ecc_req(chip, caps, oobavail))
>> > 		return 0;
>> > > 	return nand_maximize_ecc(chip, caps, oobavail);
>> > > Also, I'm not sure we should just error out when nand_check_ecc_caps()
>> > fails. What about something more robust, like:
>> >
>>   But again, It will lead in overriding the DT ECC strength parameter.
>>   We started our discussion from that point. :-)
> 
> As Boris said, let's error out instead of overriding the DT ECC
> parameters.
> 
> 
> Thanks,
> Miquèl

  reply	other threads:[~2018-06-11  9:16 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-25 12:21 [PATCH v3 00/16] Update for QCOM NAND driver Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 01/16] mtd: rawnand: helper function for setting up ECC configuration Abhishek Sahu
2018-05-26  8:42   ` Miquel Raynal
2018-05-28  5:46     ` Abhishek Sahu
2018-06-07 12:37       ` Miquel Raynal
2018-06-11  9:16         ` Abhishek Sahu [this message]
2018-06-18 10:04           ` Miquel Raynal
2018-05-29 19:30     ` Boris Brezillon
2018-05-30  0:28       ` Masahiro Yamada
2018-05-30  6:21         ` Abhishek Sahu
2018-05-30  7:38           ` Masahiro Yamada
2018-05-30  8:53             ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 02/16] mtd: rawnand: denali: use helper function for ecc setup Abhishek Sahu
2018-05-27  9:26   ` Masahiro Yamada
2018-05-25 12:21 ` [PATCH v3 03/16] dt-bindings: qcom_nandc: make nand-ecc-strength optional Abhishek Sahu
2018-05-26  8:42   ` Miquel Raynal
2018-05-28  5:53     ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 04/16] dt-bindings: qcom_nandc: remove nand-ecc-step-size Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 05/16] mtd: rawnand: qcom: remove dt property nand-ecc-step-size Abhishek Sahu
2018-05-26  8:42   ` Miquel Raynal
2018-05-26  8:42     ` Miquel Raynal
2018-05-28  5:55     ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 06/16] mtd: rawnand: qcom: use the ecc strength from device parameter Abhishek Sahu
2018-05-26  8:43   ` Miquel Raynal
2018-05-28  6:01     ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 07/16] mtd: rawnand: qcom: wait for desc completion in all BAM channels Abhishek Sahu
2018-05-26  8:43   ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 08/16] mtd: rawnand: qcom: erased page detection for uncorrectable errors only Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 09/16] mtd: rawnand: qcom: fix null pointer access for erased page detection Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 10/16] mtd: rawnand: qcom: parse read errors for read oob also Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 11/16] mtd: rawnand: qcom: modify write_oob to remove read codeword part Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 12/16] mtd: rawnand: qcom: fix return value for raw page read Abhishek Sahu
2018-05-26  8:43   ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 13/16] mtd: rawnand: qcom: minor code reorganization for bad block check Abhishek Sahu
2018-05-26  8:46   ` Miquel Raynal
2018-05-28  6:12     ` Abhishek Sahu
2018-05-28  7:03       ` Miquel Raynal
2018-05-28 10:10         ` Abhishek Sahu
2018-05-28 10:10           ` Abhishek Sahu
2018-06-07 12:53           ` Miquel Raynal
2018-06-11 13:22             ` Abhishek Sahu
2018-06-18 11:35               ` Miquel Raynal
2018-06-20  7:04                 ` Abhishek Sahu
2018-06-20  7:04                   ` Abhishek Sahu
2018-05-26  8:58   ` Miquel Raynal
2018-05-28  6:16     ` Abhishek Sahu
2018-05-28  7:09       ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 14/16] mtd: rawnand: qcom: check for operation errors in case of raw read Abhishek Sahu
2018-05-26  8:58   ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 15/16] mtd: rawnand: qcom: helper function for " Abhishek Sahu
2018-05-27 13:53   ` Miquel Raynal
2018-05-28  7:34     ` Abhishek Sahu
2018-06-07 12:43       ` Miquel Raynal
2018-06-11  9:19         ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 16/16] mtd: rawnand: qcom: erased page bitflips detection Abhishek Sahu

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=7cf002e3d7ebd46476554477dd92716f@codeaurora.org \
    --to=absahu@codeaurora.org \
    --cc=andy.gross@linaro.org \
    --cc=architt@codeaurora.org \
    --cc=boris.brezillon@bootlin.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=dwmw2@infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=yamada.masahiro@socionext.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.