linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Harvey Hunt <harveyhuntnexus@gmail.com>,
	list@opendingux.net, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/3] mtd: rawnand: Export nand_read_page_hwecc_oob_first()
Date: Fri, 15 Oct 2021 11:44:46 +0200	[thread overview]
Message-ID: <20211015114446.6a939367@xps13> (raw)
In-Reply-To: <CRI01R.KF0NPTKK5WYV1@crapouillou.net>

Hi Paul,

paul@crapouillou.net wrote on Fri, 15 Oct 2021 10:38:00 +0100:

> Hi,
> 
> Le ven., oct. 15 2021 at 11:35:15 +0200, Miquel Raynal <miquel.raynal@bootlin.com> a écrit :
> > Hi Paul,
> >   
> >>  >>  */  
> >>  >>  >> >>   /* An ECC layout for using 4-bit ECC with small-page >> flash, >> storing  
> >>  >>  >>  @@ -648,7 +580,7 @@ static int >> davinci_nand_attach_chip(struct >> >> nand_chip *chip)
> >>  >>  >>   			} else if (chunks == 4 || chunks == 8) {
> >>  >>  >>   				mtd_set_ooblayout(mtd,
> >>  >>  >>   						  nand_get_large_page_ooblayout());
> >>  >>  >>  -				chip->ecc.read_page = >> >> nand_davinci_read_page_hwecc_oob_first;
> >>  >>  >>  +				chip->ecc.read_page = nand_read_page_hwecc_oob_first;
> >>  >>  >>   			} else {
> >>  >>  >>   				return -EIO;
> >>  >>  >>   			}
> >>  >>  >>  diff --git a/drivers/mtd/nand/raw/nand_base.c >> >> >> b/drivers/mtd/nand/raw/nand_base.c
> >>  >>  >>  index 3d6c6e880520..cb5f343b9fa2 100644
> >>  >>  >>  --- a/drivers/mtd/nand/raw/nand_base.c
> >>  >>  >>  +++ b/drivers/mtd/nand/raw/nand_base.c
> >>  >>  >>  @@ -3160,6 +3160,75 @@ static int >> nand_read_page_hwecc(struct >> >> nand_chip *chip, uint8_t *buf,
> >>  >>  >>   	return max_bitflips;
> >>  >>  >>   }  
> >>  >>  >> >>  +/**  
> >>  >>  >>  + * nand_read_page_hwecc_oob_first - Hardware ECC page read >> >> with ECC
> >>  >>  >>  + *                                  data read from OOB area
> >>  >>  >>  + * @chip: nand chip info structure
> >>  >>  >>  + * @buf: buffer to store read data
> >>  >>  >>  + * @oob_required: caller requires OOB data read to >> >> chip->oob_poi
> >>  >>  >>  + * @page: page number to read
> >>  >>  >>  + *
> >>  >>  >>  + * Hardware ECC for large page chips, require OOB to be >> read >> >> first. For this  
> >>  >>  >
> >>  >>  > requires
> >>  >>  >
> >>  >>  > With this ECC configuration?
> >>  >>  >  
> >>  >>  >>  + * ECC mode, the write_page method is re-used from ECC_HW. >> >> These >> methods  
> >>  >>  >
> >>  >>  > I do not understand this sentence nor the next one about >> >> syndrome. I
> >>  >>  > believe it is related to your engine and should not leak into >> the >> > core.
> >>  >>  >  
> >>  >>  >>  + * read/write ECC from the OOB area, unlike the >> >> ECC_HW_SYNDROME >> support with
> >>  >>  >>  + * multiple ECC steps, follows the "infix ECC" scheme and >> >> >> reads/writes ECC from
> >>  >>  >>  + * the data area, by overwriting the NAND manufacturer bad >> >> block >> markings.  
> >>  >>  >
> >>  >>  > That's a sentence I don't like. What do you mean exactly?
> >>  >>  >
> >>  >>  > What "Infix ECC" scheme is?
> >>  >>  >
> >>  >>  > Do you mean that unlike the syndrome  mode it *does not* >> >> overwrite the
> >>  >>  > BBM ?  
> >>  >> >>  I don't mean anything. I did not write that comment. I just >> moved >> the function verbatim with no changes. If something needs >> to be >> fixed, then it needs to be fixed before/after this patch.  
> >>  >
> >>  > Well, this comment should be adapted because as-is I don't think >> it's
> >>  > wise to move it around.  
> >> >>  OK.
> >> >>  I think it says that BBM can be overwritten with this >> configuration, but that would be if the OOB layout covers the BBM >> area.  
> > 
> > If the ooblayout prevents the BBM to be smatched I'm fine and this
> > sentence should disappear because it's misleading.
> >   
> >>  >> >>  >>  + */  
> >>  >>  >>  +int nand_read_page_hwecc_oob_first(struct nand_chip *chip, >> >> uint8_t >> *buf,
> >>  >>  >>  +				   int oob_required, int page)
> >>  >>  >>  +{
> >>  >>  >>  +	struct mtd_info *mtd = nand_to_mtd(chip);
> >>  >>  >>  +	int i, eccsize = chip->ecc.size, ret;
> >>  >>  >>  +	int eccbytes = chip->ecc.bytes;
> >>  >>  >>  +	int eccsteps = chip->ecc.steps;
> >>  >>  >>  +	uint8_t *p = buf;
> >>  >>  >>  +	uint8_t *ecc_code = chip->ecc.code_buf;
> >>  >>  >>  +	unsigned int max_bitflips = 0;
> >>  >>  >>  +
> >>  >>  >>  +	/* Read the OOB area first */
> >>  >>  >>  +	ret = nand_read_oob_op(chip, page, 0, chip->oob_poi, >> >> >> mtd->oobsize);
> >>  >>  >>  +	if (ret)
> >>  >>  >>  +		return ret;
> >>  >>  >>  +
> >>  >>  >>  +	ret = nand_read_page_op(chip, page, 0, NULL, 0);  
> >>  >>  >
> >>  >>  > Definitely not, your are requesting the chip to do the >> read_page
> >>  >>  > operation twice. You only need a nand_change_read_column I >> >> believe.  
> >>  >> >>  Again, this code is just being moved around - don't shoot >> the >> messenger :)  
> >>  >
> >>  > haha
> >>  >
> >>  > Well, now you touch the core, so I need to be more careful, and >> the
> >>  > code is definitely wrong, so even if we don't move that code off, >> you
> >>  > definitely want to fix it in order to improve your performances.  
> >> >>  I don't see the read_page being done twice?
> >> >>  There's one read_oob, one read_page, then read_data in the loop.  
> > 
> > read_oob and read_page both end up sending READ0 and READSTART so
> > they do request the chip to perform an internal read twice. You
> > need this only once. The call to nand_read_page_op() should be a
> > nand_change_read_column() with no data requested.  
> 
> OK.
> 
> >   
> >>  >>  >>   /**
> >>  >>  >>    * nand_read_page_syndrome - [REPLACEABLE] hardware ECC >> >> syndrome >> based page read
> >>  >>  >>    * @chip: nand chip info structure
> >>  >>  >>  diff --git a/include/linux/mtd/rawnand.h >> >> >> b/include/linux/mtd/rawnand.h
> >>  >>  >>  index b2f9dd3cbd69..5b88cd51fadb 100644
> >>  >>  >>  --- a/include/linux/mtd/rawnand.h
> >>  >>  >>  +++ b/include/linux/mtd/rawnand.h
> >>  >>  >>  @@ -1539,6 +1539,8 @@ int nand_read_data_op(struct >> nand_chip >> *chip, >> void *buf, unsigned int len,
> >>  >>  >>   		      bool force_8bit, bool check_only);
> >>  >>  >>   int nand_write_data_op(struct nand_chip *chip, const void >> *buf,
> >>  >>  >>   		       unsigned int len, bool force_8bit);
> >>  >>  >>  +int nand_read_page_hwecc_oob_first(struct nand_chip *chip, >> >> uint8_t >> *buf,
> >>  >>  >>  +				   int oob_required, int page);  
> >>  >>  >
> >>  >>  > You certainly want to add this symbol closer to the other >> >> read/write
> >>  >>  > page helpers?  
> >>  >> >>  Where would that be? The other read/write page helpers are >> all >> "static" so they don't appear in any header.  
> >>  >
> >>  > I believe we should keep this header local as long as there are no
> >>  > other users.  
> >> >>  I'll move it to internal.h then.  
> > 
> > Why do you want to put it there is there is only one user?  
> 
> But there are two users: davinci_nand.c and (with patch [3/3]) ingenic/ingenic_nand_drv.c.

Oh right I missed that :)

Then please add two preparation patches which:
- fixes the comment (please reword it completely)
- avoid the double reading

And keep the location where you moved it (including the header) as-is.

Thanks,
Miquèl

  reply	other threads:[~2021-10-15  9:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-09 18:49 [PATCH 0/3] mtd: Ingenic NAND fix for JZ4740 Paul Cercueil
2021-10-09 18:49 ` [PATCH 1/3] mtd: rawnand/davinci: Don't calculate ECC when reading page Paul Cercueil
2021-10-09 18:49 ` [PATCH 2/3] mtd: rawnand: Export nand_read_page_hwecc_oob_first() Paul Cercueil
2021-10-15  6:13   ` Miquel Raynal
2021-10-15  8:38     ` Paul Cercueil
2021-10-15  8:51       ` Miquel Raynal
2021-10-15  9:27         ` Paul Cercueil
2021-10-15  9:35           ` Miquel Raynal
2021-10-15  9:38             ` Paul Cercueil
2021-10-15  9:44               ` Miquel Raynal [this message]
2021-10-09 18:49 ` [PATCH 3/3] mtd: rawnand/ingenic: JZ4740 needs 'oob_first' read page function Paul Cercueil
2021-10-15  6:14   ` Miquel Raynal
2021-11-07 13:47 ` [PATCH 0/3] mtd: Ingenic NAND fix for JZ4740 H. Nikolaus Schaller
2021-11-07 18:43   ` Paul Cercueil

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=20211015114446.6a939367@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=harveyhuntnexus@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=list@opendingux.net \
    --cc=paul@crapouillou.net \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    --cc=vigneshr@ti.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 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).