From: Miquel Raynal <miquel.raynal@bootlin.com>
To: masonccyang@mxic.com.tw
Cc: bbrezillon@kernel.org,
"Boris Brezillon" <boris.brezillon@collabora.com>,
computersforpeace@gmail.com, dwmw2@infradead.org,
juliensu@mxic.com.tw, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, marek.vasut@gmail.com,
richard@nod.at, zhengxunli@mxic.com.tw
Subject: Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer support
Date: Mon, 29 Apr 2019 11:34:06 +0200 [thread overview]
Message-ID: <20190429113406.09d5b68f@xps13> (raw)
In-Reply-To: <OFD55A67FA.88C5BFBC-ON482583E0.0011385B-482583E0.00133C32@mxic.com.tw>
Hi Mason, Boris,
masonccyang@mxic.com.tw wrote on Thu, 18 Apr 2019 11:30:05 +0800:
> Hi Miquel,
>
>
> > > > > > > > > >
> > > > > > > > > > Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry
> and
> > > > > > > randomizer
> > > > > > > > > support
> > > > > > > > > >
> > > > > > > > > > On Tue, 9 Apr 2019 17:35:39 +0800
> > > > > > > > > > masonccyang@mxic.com.tw wrote:
> > > > > > > > > >
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +static const struct kobj_attribute
> sysfs_mxic_nand =
> > > > > > > > > > > > > + __ATTR(nand_random, S_IRUGO | S_IWUSR,
> > > > > > > > > > > > > + mxic_nand_rand_type_show,
> > > > > > > > > > > > > + mxic_nand_rand_type_store);
> > > > > > > > > > > >
> > > > > > > > > > > > No, we don't want to expose that through a sysfs
> file,
> > > > > > > especially
> > > > > > > > > since
> > > > > > > > > > > > changing the randomizer config means making the NAND
>
> > > > > unreadable
> > > > > > > for
> > > > > > > > > > > > those that have used it before the change.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Our on-die randomizer is still readable from user
> after
> > > the
> > > > > > > function
> > > > > > > > > > > is enabled.
> > > > > > > > > >
> > > > > > > > > > You mean the memory is still readable no matter the
> > > randomizer
> > > > > > > state.
> > > > > > > > > > Not sure how that's possible, but okay.
> > > > > > > > > >
> > > > > > > > > > > This randomizer is just like a internal memory cell
> > > > > > > > > > > reliability enhanced.
> > > > > > > > > >
> > > > > > > > > > Why don't you enable it by default then?
> > > > > > > > >
> > > > > > > > > The penalty of randomizer is read/write performance down.
> > > > > > > > > i.e,. tPROG 300 us to 340 us (randomizer enable)
> > > > > > > > > therefore, disable it by default.
> > > > > > > >
> > > > > > > > I'm a bit puzzled. On the NAND I've seen that required data
> > > > > > > > randomization it's not something you'd want to disable as
> this
> > > > > implied
> > > > > > > > poor data retention. What's the use case here? Are we
> talking
> > > about
> > > > > SLC
> > > > > > > > or MLC NANDs? Should we enable this feature once we
> > start seeing
> > >
> > > > > that
> > > > > > > > the NAND starts being less reliable (basically when
> read-retry
> > > > > happens
> > > > > > > > more often)? I really think this is something you
> shoulddecide
> > >
> > > > > kernel
> > > > > > > > side, because users have no clue when it's appropriate
> > to switch
> > >
> > > > > this
> > > > > > > > feature on/off.
> > > > > > > >
> > > > > > >
> > > > > > > It's SLC NAND and seems to has nothing to do with read-retry
> > > happens.
> > > > > > > later, I will get more information for your concerns.
> > > > > >
> > > > > > Well, this feature is optional, and can be enabled to improve
> > > > > > reliability. Sounds like a good reason to enable it when your
> NAND
> > > > > > device starts showing reliability issues, and the number of
> > > read_retry
> > > > > > attempts reflects the wear level pretty well. Alternatively, you
>
> > > could
> > > > > > use the number of bitflips, but, in any case, don't expect the
> user
> > > to
> > > > > > take this decision, because almost nobody knows what the
> randomizer
> > > > > > is needed for.
> > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > It could be enable at any time with OTP bit function
> and
> > > > > that's
> > > > > > > why
> > > > > > > > > > > we patch it by sys-fs.
> > > > > > > > > >
> > > > > > > > > > Sorry, but that's not a good reason to expose that
> through
> > > > > sysfs.
> > > > > > > > >
> > > > > > > > > Any good way to expose randomizer function for user ?
> > > > > > > >
> > > > > > > > Don't expose it :P.
> > > > > > >
> > > > > > > oh, okay, I will remove sys-fs randomizer.
> > > > > > >
> > > > > > > Is it OK to keep set/get features for randomizer ?
> > > > > >
> > > > > > I don't think it's a good idea to have dead code, so no. But I'm
>
> > > pretty
> > > > > > sure we'll find a way to use/expose this feature.
> > > > >
> > > > > okay, great!
> > > > > Looking forward to hearing this feature use/expose.
> > > >
> > > > But for that to happen we are waiting for inputs about when this is
> > > > supposed to be used...
> > >
> > >
> > > The main reason to disable Randomizer in default is
> > > NOP = 4 (default) change to NOP = 1 (Randomizer enable),
> > > NOP: number of partial program cycles in same page
> >
> > I am not sure to understand, is this related to what we call 'subpages'?
> >
> yes,
>
> > >
> > > Some OS file systems(or FTL) much concern NOP = 4 and
> > > any better way than sys-fs to enable it?
> >
> > sysfs entry => user action
> > The user has absolutely no way to know when it is relevant to enable
> > the randomizer. The kernel must be in charge of it. So the question is:
> > when is it relevant to enable the randomizer? What criteria? What
> > threshold?
> >
>
> Randomizer is according to users' demand that at least two different use
> cases.
> 1. a need for an operation mode/use case to take advantage of NOP of 4
> without turning on randomizer
> 2. another use case for high data integrity by enabling randomizer and
> sacrificing NOP
>
> If user application don't need subpage program (NOP = 1 is ok),
> they could enable Randomizer from kernel driver
> (i.e., chip->options |= NAND_NO_SUBPAGE_WRITE; & set feature to enable
> randomizer)
> or user space(i.e., sys-fs.).
>
> Therefore, default to disbale randomizer(for NOP=4).
What about a DT property in the NAND chip node that would be checked in
Macronix driver? Or maybe a defconfig entry? This cannot be changed at
runtime.
Thanks,
Miquèl
next prev parent reply other threads:[~2019-04-29 9:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 3:22 [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer support Mason Yang
2019-04-09 7:04 ` Boris Brezillon
[not found] ` <OF6C97E4DE.45261545-ON482583D7.00340468-482583D7.0034B3FE@mxic.com.tw>
2019-04-09 9:47 ` Boris Brezillon
[not found] ` <OF9601E14B.A48284C4-ON482583D8.0005E3EB-482583D8.0006CC14@mxic.com.tw>
2019-04-10 7:16 ` Miquel Raynal
[not found] ` <OF37AF39D0.77A1B5F5-ON482583D8.002E12E6-482583D8.002FA5B1@mxic.com.tw>
2019-04-10 9:15 ` Miquel Raynal
2019-04-10 7:22 ` Boris Brezillon
[not found] ` <OF071D3608.9D6D2523-ON482583D9.00173F52-482583D9.0018188C@mxic.com.tw>
2019-04-11 6:53 ` Boris Brezillon
[not found] ` <OF34672B6F.AACFE22C-ON482583D9.00335814-482583D9.0033A673@mxic.com.tw>
2019-04-11 9:29 ` Boris Brezillon
[not found] ` <OF84BD5411.301E92AC-ON482583DF.000CC3CC-482583DF.000F4920@mxic.com.tw>
2019-04-17 7:08 ` Miquel Raynal
[not found] ` <OFD55A67FA.88C5BFBC-ON482583E0.0011385B-482583E0.00133C32@mxic.com.tw>
2019-04-29 9:34 ` Miquel Raynal [this message]
2019-04-17 7:11 ` Boris Brezillon
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=20190429113406.09d5b68f@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=bbrezillon@kernel.org \
--cc=boris.brezillon@collabora.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=juliensu@mxic.com.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=masonccyang@mxic.com.tw \
--cc=richard@nod.at \
--cc=zhengxunli@mxic.com.tw \
/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).