From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Wojtaszczyk, Piotr" <WojtaszczykP@cumminsallison.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>,
Miquel Raynal <miquel.raynal@bootlin.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
Bean Huo <beanhuo@micron.com>
Subject: Re: [RFC PATCH 0/3] Fix proposal for the Micron shallow erase issue
Date: Wed, 15 Jan 2020 08:58:06 +0100 [thread overview]
Message-ID: <20200115085806.218b6b32@collabora.com> (raw)
In-Reply-To: <8fac8e86-3455-271d-2fcb-c2a6070e8127@cumminsallison.com>
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.
>
> 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.
>
> Instead we could check a flag in OOB area of first page of the PEB we are about to erase
> and clear the flag bit/bits when 16th page of the PEB gets programmed. Simmilar to bad
> block mark.
Well, that doesn't work well because:
1/ programming a page that has already be programmed is not always
allowed (you must have sub-page write support and the page must have
been programmed less than the number of subpage writes)
2/ controller side ECCs are in the way, and we don't have a proper
solution to describe unprotected OOB regions. Even if we had
that in place, there might not even be such unprotected OOB left
(some controllers protect/use the whole OOB area)
Note that the writes we do in micron_nand_avoid_shallow_erase() will
corrupt data present in those pages, but that shouldn't be a problem,
because we want to erase them anyway.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-01-15 7:58 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 [this message]
2020-01-15 8:13 ` Miquel Raynal
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=20200115085806.218b6b32@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=WojtaszczykP@cumminsallison.com \
--cc=beanhuo@micron.com \
--cc=f.fainelli@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--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;
as well as URLs for NNTP newsgroup(s).