From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Richard Weinberger <richard@nod.at>,
Zoltan Szubbocsev <zszubbocsev@micron.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Wojtaszczyk, Piotr" <WojtaszczykP@cumminsallison.com>,
Bean Huo <beanhuo@micron.com>
Subject: Re: [RFC PATCH 0/3] Fix proposal for the Micron shallow erase issue
Date: Wed, 15 Jan 2020 09:13:25 +0100 [thread overview]
Message-ID: <20200115091325.667c06a8@xps13> (raw)
In-Reply-To: <20200115085806.218b6b32@collabora.com>
Hi Boris,
Boris Brezillon <boris.brezillon@collabora.com> wrote on Wed, 15 Jan
2020 08:58:06 +0100:
> On Tue, 14 Jan 2020 20:46:17 +0000
> "Wojtaszczyk, Piotr" <WojtaszczykP@cumminsallison.com> wrote:
>
> > On 1/14/20 3:12 AM, Miquel Raynal wrote:
> > > Crap. I'll not resend immediately as this is an RFC, I expect
> > > feedback on this proposal before sending an actual patch.
> > >
> > >
> > > Thanks,
> > > Miquèl
> > >
> >
> > Hi Miquèl, here are some my comments:
> >
> > +static int micron_nand_avoid_shallow_erase(struct nand_chip *chip,
> > + unsigned int eb)
> > +{
> > + struct micron_nand *micron = nand_get_manufacturer_data(chip);
> > + unsigned int page = eb * nanddev_pages_per_eraseblock(&chip->base);
> > + u8 *databuf = nand_get_data_buf(chip);
> > + int ret, i;
> > +
> > + memset(databuf, 0xFF, nanddev_page_size(&chip->base));
> > +
> > + /* Micron advises to only write odd pages */
> > + for (i = 0; i < MICRON_SHALLOW_ERASE_MIN_PAGE; i += 2, page += 2) {
> > + if (!(micron->writtenp[eb] & BIT(i))) {
> > + ret = nand_write_page_raw(chip, databuf, false, page);
> > + if (ret)
> > + return ret;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> >
> > Shouldn't we program only the OOB area of the pages to 0'es? Programming pages to 0xFF
> > which are already 0xFF takes more time and doesn't make any difference.
>
> Hm, I'm pretty sure we should set in-band data to 0, not 0xff.
> Programming only the OOB portion might not be enough for the internal
> "is page written?" logic to return true.
Absolutely, this is a mistake, the idea is to program all cells (to 0).
> > Also after power loss all flags in micron->writtenp are gone so the
> > micron_nand_avoid_shallow_erase will perform on all PEBs causing performance loss.
>
> Yes, that's a performance hit we'll have to accept for now.
>
This is quite severe issue, this is the best idea we came with to
limit performance hits.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-01-15 8:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-31 19:26 [RFC PATCH 0/3] Fix proposal for the Micron shallow erase issue Miquel Raynal
2019-12-31 19:26 ` [RFC PATCH 1/3] mtd: rawnand: Add the nand_chip->erase hook Miquel Raynal
2019-12-31 19:26 ` [RFC PATCH 2/3] mtd: rawnand: Add the nand_chip->write_oob hook Miquel Raynal
2019-12-31 19:26 ` [RFC PATCH 3/3] mtd: rawnand: micron: Address the shallow erase issue Miquel Raynal
2020-01-02 18:41 ` [RFC PATCH 0/3] Fix proposal for the Micron " Florian Fainelli
2020-01-14 9:12 ` Miquel Raynal
2020-01-14 20:46 ` Wojtaszczyk, Piotr
2020-01-15 7:58 ` Boris Brezillon
2020-01-15 8:13 ` Miquel Raynal [this message]
2020-01-15 16:51 ` Wojtaszczyk, Piotr
2020-05-03 11:29 ` Miquel Raynal
2020-05-04 8:08 ` [EXT] " Bean Huo (beanhuo)
2020-05-04 8:26 ` Miquel Raynal
2020-05-06 15:36 ` Bean Huo (beanhuo)
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=20200115091325.667c06a8@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=WojtaszczykP@cumminsallison.com \
--cc=beanhuo@micron.com \
--cc=boris.brezillon@collabora.com \
--cc=f.fainelli@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=tglx@linutronix.de \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.com \
--cc=zszubbocsev@micron.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