From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Wojtaszczyk, Piotr" <WojtaszczykP@cumminsallison.com>,
Bean Huo <beanhuo@micron.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Zoltan Szubbocsev <zszubbocsev@micron.com>,
Richard Weinberger <richard@nod.at>,
Boris Brezillon <boris.brezillon@collabora.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [RFC PATCH 0/3] Fix proposal for the Micron shallow erase issue
Date: Sun, 3 May 2020 13:29:13 +0200 [thread overview]
Message-ID: <20200503132913.40b739a3@xps13> (raw)
In-Reply-To: <c2bf2161-7122-4d59-3e51-57db27654685@cumminsallison.com>
Hi Bean,
There are two technical questions below that I would like you to answer.
> >>> 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.
>
> This will be an issue on devices which restarts quite often, what if we read OOB of middle
> page of the block we are about to erase and if it has all 0xff the it means it is
> partially programmed and needs the quirk. It's reading 64/128 bytes (depending on NAND
> size) before every erase versus programming 8 pages on each PEB erase once per device restart.
>
> Also I know by speaking with Micron that programming 0 in spare area is enough and
> actually we should program 8 even/odd pages starting from middle of PEB. In case PEB has
> 64 pages we should program OOB of page 31,33,35,37,39,41,43,45 or 32,34,36,38,40,42,44,46
> Can somebody from Micron confirm that?
So the questions are:
1/ What should we write exactly:
-> the main area
-> the OOB area
-> both
?
2/ Shall we prefer writing 8 even/odd pages starting from:
-> the beginning of the
-> the middle of the block
-> we do not care
?
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-05-03 11:29 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
2020-01-15 16:51 ` Wojtaszczyk, Piotr
2020-05-03 11:29 ` Miquel Raynal [this message]
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=20200503132913.40b739a3@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 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.