public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Christophe Kerello <christophe.kerello@foss.st.com>
Cc: "Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Tudor Ambarus" <tudor.ambarus@linaro.org>,
	"Pratyush Yadav" <pratyush@kernel.org>,
	"Michael Walle" <michael@walle.cc>,
	linux-mtd@lists.infradead.org,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Julien Su" <juliensu@mxic.com.tw>,
	"Jaime Liao" <jaimeliao@mxic.com.tw>,
	"Jaime Liao" <jaimeliao.tw@gmail.com>,
	"Alvin Zhou" <alvinzhou@mxic.com.tw>,
	eagle.alexander923@gmail.com, mans@mansr.com, martin@geanix.com,
	"Sean Nyekjær" <sean@geanix.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 4/4] mtd: rawnand: Clarify conditions to enable continuous reads
Date: Wed, 21 Feb 2024 17:53:27 +0100	[thread overview]
Message-ID: <20240221175327.42f7076d@xps-13> (raw)
In-Reply-To: <8ed32443-1343-4970-9f5a-34285850b372@foss.st.com>

Hi Christophe,

christophe.kerello@foss.st.com wrote on Wed, 21 Feb 2024 17:29:45 +0100:

> Hi Miquel,
> 
> On 2/21/24 12:20, Miquel Raynal wrote:
> > Hi Christophe,
> > 
> > christophe.kerello@foss.st.com wrote on Fri, 9 Feb 2024 14:35:44 +0100:
> >   
> >> Hi Miquel,
> >>
> >> I am testing last nand/next branch with the MP1 board, and i get an issue since this patch was applied.
> >>
> >> When I read the SLC NAND using nandump tool (reading page 0 and page 1), the OOB is not displayed at expected. For page 1, oob is displayed when for page 0 the first data of the page are displayed.
> >>
> >> The nanddump command used is: nanddump -c -o -l 0x2000 /dev/mtd9  
> > 
> > I believe the issue is not in the indexes but related to the OOB. I
> > currently test on a device on which I would prefer not to smash the
> > content, so this is just compile tested and not run time verified, but
> > could you tell me if this solves the issue:
> > 
> > --- a/drivers/mtd/nand/raw/nand_base.c
> > +++ b/drivers/mtd/nand/raw/nand_base.c
> > @@ -3577,7 +3577,8 @@ static int nand_do_read_ops(struct nand_chip *chip, loff_t from,
> >          oob = ops->oobbuf;
> >          oob_required = oob ? 1 : 0;  
> >   > -       rawnand_enable_cont_reads(chip, page, readlen, col);  
> > +       if (!oob_required)
> > +               rawnand_enable_cont_reads(chip, page, readlen, col);  
> 
> I am still able to reproduce the problem with the patch applied.
> In fact, when nanddump reads the OOB, nand_do_read_ops is not called, but nand_read_oob_op is called, and as cont_read.ongoing=1, we are not dumping the oob but the first data of the page.
> 
> page 0:
> [   57.642144] rawnand_enable_cont_reads: page=0, col=0, readlen=4096, mtd->writesize=4096
> [   57.650210] rawnand_enable_cont_reads: end_page=1
> [   57.654858] nand_do_read_ops: cont_read.ongoing=1
> [   59.352562] nand_read_oob_op
> page 1:
> [   59.355966] rawnand_enable_cont_reads: page=1, col=0, readlen=4096, mtd->writesize=4096
> [   59.364045] rawnand_enable_cont_reads: end_page=1
> [   59.368757] nand_do_read_ops: cont_read.ongoing=0
> [   61.390098] nand_read_oob_op
> 
> I have not currently bandwidth to work on this topic and I need to understand how continuous read is working, but I have made a patch and I do not have issues with it when I am using nanddump or mtd_debug tools.

Actually since my previous answer I managed to reproduce the issue. I
was unable to do it because I was testing at the beginning of the
second partition, instead of the beginning of the device. I also
observe the same behavior.

> I have not tested it on a file system, so it is just a proposal.
>
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -3466,22 +3466,18 @@ static void rawnand_enable_cont_reads(struct nand_chip *chip, unsigned int page,
>   				      u32 readlen, int col)
>   {
>   	struct mtd_info *mtd = nand_to_mtd(chip);
> -	unsigned int end_page, end_col;
> +	unsigned int end_page;
> 
>   	chip->cont_read.ongoing = false;
> 
> -	if (!chip->controller->supported_op.cont_read)
> +	if (!chip->controller->supported_op.cont_read || col + readlen <= mtd->writesize)
>   		return;
> 
> -	end_page = DIV_ROUND_UP(col + readlen, mtd->writesize);
> +	end_page = page + DIV_ROUND_UP(col + readlen, mtd->writesize) - 1;

I had a similar change on my side so I believe this is needed.

> -	end_col = (col + readlen) % mtd->writesize;

We shall ensure we only enable continuous reads on full pages, to avoid
conflicts with the core trying to optimize things out. So I believe
this change won't fly, but I get the idea, there is definitely
something to fix there.

> 
>   	if (col)
>   		page++;
> 
> -	if (end_col && end_page)
> -		end_page--;
> -
>   	if (page + 1 > end_page)
>   		return;
> 
> Tell me if this patch is breaking the continuous read feature or if it can be pushed on the mailing list.

I'll have deeper look into this tomorrow and get back to you. Thanks a
lot for the proposal though, I will work on it.

> 
> Regards,
> Christophe Kerello.
> 
> >   >          while (1) {  
> >                  struct mtd_ecc_stats ecc_stats = mtd->ecc_stats;
> > 
> > 
> > If that does not work, I'll destroy the content of the flash and
> > properly reproduce.
> > 
> > Thanks,
> > Miquèl  


Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2024-02-21 16:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-15 12:32 [PATCH 0/4] mtd: rawnand: Fix sequential reads Miquel Raynal
2023-12-15 12:32 ` [PATCH 1/4] mtd: rawnand: Prevent crossing LUN boundaries during " Miquel Raynal
2023-12-22 11:37   ` Miquel Raynal
2023-12-15 12:32 ` [PATCH 2/4] mtd: rawnand: Fix core interference with " Miquel Raynal
2023-12-22 11:37   ` Miquel Raynal
2023-12-15 12:32 ` [PATCH 3/4] mtd: rawnand: Prevent sequential reads with on-die ECC engines Miquel Raynal
2023-12-22 11:37   ` Miquel Raynal
2023-12-15 12:32 ` [PATCH 4/4] mtd: rawnand: Clarify conditions to enable continuous reads Miquel Raynal
2023-12-22 11:37   ` Miquel Raynal
2024-02-09 13:35     ` Christophe Kerello
2024-02-13 19:39       ` Miquel Raynal
2024-02-21 11:20       ` Miquel Raynal
2024-02-21 16:29         ` Christophe Kerello
2024-02-21 16:53           ` Miquel Raynal [this message]
2023-12-21 10:06 ` [PATCH 0/4] mtd: rawnand: Fix sequential reads Martin Hundebøll

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=20240221175327.42f7076d@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=alvinzhou@mxic.com.tw \
    --cc=christophe.kerello@foss.st.com \
    --cc=eagle.alexander923@gmail.com \
    --cc=jaimeliao.tw@gmail.com \
    --cc=jaimeliao@mxic.com.tw \
    --cc=juliensu@mxic.com.tw \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mans@mansr.com \
    --cc=martin@geanix.com \
    --cc=michael@walle.cc \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=sean@geanix.com \
    --cc=stable@vger.kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tudor.ambarus@linaro.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