From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Petr Kulhavy <petr@barix.com>
Cc: Murali Karicheri <m-karicheri2@ti.com>, linux-mtd@lists.infradead.org
Subject: Re: DaVinci NAND: disable subpage write (28c015)
Date: Fri, 22 Apr 2016 14:09:34 +0200 [thread overview]
Message-ID: <20160422140934.018d46bc@bbrezillon> (raw)
In-Reply-To: <571A0FE1.4040202@barix.com>
On Fri, 22 Apr 2016 13:49:53 +0200
Petr Kulhavy <petr@barix.com> wrote:
> Hi Boris,
>
> On 22.04.2016 11:05, Boris Brezillon wrote:
> > Hi Petr,
> >
> > On Fri, 22 Apr 2016 10:20:09 +0200
> > Petr Kulhavy <petr@barix.com> wrote:
> >
> >> Hi,
> >>
> >> this email refers to the commit:
> >> 28c015a9daabe4ed3aeb0ccf669a3f1c2b8b81d5 on drivers/mtd/nand/davinci-nand.c.
> >> This commit sets the NAND_NO_SUBPAGE_WRITE option for "ti,keystone-nand"
> >> to workaround a HW issue on the controller.
> >>
> >> Disabling subpage write however should be made a general option because
> >> some NAND chips do not support subpage write at all. Subpage write is a
> >> feature of the NAND chip, not the NAND interface. In combination with
> >> "ti,davinci-nand" there is no option to disable subpage write.
> >> In my case I'm struggling with this issue on the AM1808 with a 1Gb
> >> Micron NAND (MT29F1GxxABB).
> > That's true that subpage write is initially a feature exposed by NAND
> > chips (actually called subpage in datasheets), but the controller can
> > say that it does not support writing subpages.
> > The problem is, in most drivers we don't have the concept of
> > controllers, hence the reason we're asking NAND controllers to
> > explicitly modify chip->options and set the NAND_NO_SUBPAGE_WRITE flag
> > manually.
> >
> > Note that, unless the CHIP supports subpage write, mtd->subpage_sft
> > will be 0, which should prevent subpage writes [1].
>
> Thank you for the explanation. Do you mean that the controller should
> detect if the chip supports subpage writing?
No, the controller should just care about what it supports, not what
the chip supports.
> Where is the piece of code
> doing the detection?
Actually, according to the code I pointed out, all SLC NANDs support
subpage write. For NANDs with really small pages (<= 512bytes), you'll
always have pagesize == subpagesize, because step usually is 512 or
1024.
For SLC NANDs with larger pages (>= 2K), then your subpage size will
depend on the number of ECC steps your have in a single page.
I realize that this approach is not entirely safe, because ecc->steps
is deduced from ecc->size which can be overloaded by NAND controller
drivers. Maybe this should be extracted from ->ecc_step_size_ds, or
even better, be encoded into a separate field, but I'm not sure this is
related to the problem you're facing.
> That is interesting, because in my case the detection does not work.
What do you get in chip->subpagesize.
According to the MT29F1GxxABB datasheet you can program a single page
up to 8 times without needing an erase operation:
"
PROGRAM PAGE 80h-10h
Micron NAND Flash devices also support partial-page programming
operations. This means that any single bit can only be programmed one
time before an erase is required; however, the page can be partitioned
so that a maximum of eight programming operations are supported before
an erase is required.
"
Which means your NAND exposes subpages, and according to the code I
pointed out, you should have 4 subpages inside a page, each of them
containing 512 bytes.
> Using compatible string "ti,davinci-nand" causes heavy ECC errors with
> UBI (which extensively uses subpage writes) and after setting the
> compatible string to "ti,keystone-nand" the errors are gone...
Then, maybe this is your controller (or the driver implementation) that
does not support writing subpages...
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
prev parent reply other threads:[~2016-04-22 12:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 8:20 DaVinci NAND: disable subpage write (28c015) Petr Kulhavy
2016-04-22 9:05 ` Boris Brezillon
2016-04-22 11:49 ` Petr Kulhavy
2016-04-22 12:09 ` Boris Brezillon [this message]
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=20160422140934.018d46bc@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=linux-mtd@lists.infradead.org \
--cc=m-karicheri2@ti.com \
--cc=petr@barix.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