From: Marek Vasut <marex@denx.de>
To: grmoore@altera.com
Cc: ggrahammoore@gmail.com,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Jingoo Han <jg1.han@samsung.com>,
Geert Uytterhoeven <geert+renesas@linux-m68k.org>,
linux-kernel@vger.kernel.org,
Yves Vandervennet <rocket.yvanderv@gmail.com>,
linux-mtd@lists.infradead.org,
Insop Song <insop.song@gainspeed.com>,
Alan Tull <atull@altera.com>,
Sourav Poddar <sourav.poddar@ti.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Gerhard Sittig <gsi@denx.de>, Dinh Nguyen <dinguyen@altera.com>
Subject: Re: [PATCH] Add support for flag status register on Micron chips
Date: Wed, 9 Apr 2014 12:03:24 +0200 [thread overview]
Message-ID: <201404091203.24956.marex@denx.de> (raw)
In-Reply-To: <1396973570-13995-1-git-send-email-grmoore@altera.com>
On Tuesday, April 08, 2014 at 06:12:49 PM, grmoore@altera.com wrote:
> From: Graham Moore <grmoore@altera.com>
>
> This is a slightly different version of the patch that Insop Song
> submitted
> (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de).
>
> I talked to Insop, and he agreed I should submit this patch as a follow-on
> to his.
>
> This patch uses a flag in the m25p_ids[] array to determine which chips
> need to use the FSR (Flag Status Register).
>
> Rationale for using the FSR:
>
> The Micron data sheets say we have to do this, at least for the multi-die
> 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check
> the FSR for program/erase status, and we rely solely on the status
> register (SR), then we get corrupted data in the flash.
I talked to Gerhard yesterday and he told me there is something like that on
ONFI NAND. I think I now understand why that new register is in-place.
Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and
one of those reflects that _all_ the dies have finished their operation. This is
in my opinion seriously misdesigned as it breaks any kind of backward
compatibility.
> Micron told us (Altera) that for multi-die chips based on the 65nm 256MB
> die, we need to check the SR first, then check the FSR, which is why the
> wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB
> die will use the FSR only.
Can these SPI flash makers screw the design even more? OT: Why don't we have a
single standard for all the SF chips which won't need all these crappy quirks
:-(
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: grmoore@altera.com
Cc: ggrahammoore@gmail.com, David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
Sourav Poddar <sourav.poddar@ti.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Geert Uytterhoeven <geert+renesas@linux-m68k.org>,
Jingoo Han <jg1.han@samsung.com>,
Insop Song <insop.song@gainspeed.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Alan Tull <atull@altera.com>, Dinh Nguyen <dinguyen@altera.com>,
Yves Vandervennet <rocket.yvanderv@gmail.com>,
Gerhard Sittig <gsi@denx.de>
Subject: Re: [PATCH] Add support for flag status register on Micron chips
Date: Wed, 9 Apr 2014 12:03:24 +0200 [thread overview]
Message-ID: <201404091203.24956.marex@denx.de> (raw)
In-Reply-To: <1396973570-13995-1-git-send-email-grmoore@altera.com>
On Tuesday, April 08, 2014 at 06:12:49 PM, grmoore@altera.com wrote:
> From: Graham Moore <grmoore@altera.com>
>
> This is a slightly different version of the patch that Insop Song
> submitted
> (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de).
>
> I talked to Insop, and he agreed I should submit this patch as a follow-on
> to his.
>
> This patch uses a flag in the m25p_ids[] array to determine which chips
> need to use the FSR (Flag Status Register).
>
> Rationale for using the FSR:
>
> The Micron data sheets say we have to do this, at least for the multi-die
> 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check
> the FSR for program/erase status, and we rely solely on the status
> register (SR), then we get corrupted data in the flash.
I talked to Gerhard yesterday and he told me there is something like that on
ONFI NAND. I think I now understand why that new register is in-place.
Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and
one of those reflects that _all_ the dies have finished their operation. This is
in my opinion seriously misdesigned as it breaks any kind of backward
compatibility.
> Micron told us (Altera) that for multi-die chips based on the 65nm 256MB
> die, we need to check the SR first, then check the FSR, which is why the
> wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB
> die will use the FSR only.
Can these SPI flash makers screw the design even more? OT: Why don't we have a
single standard for all the SF chips which won't need all these crappy quirks
:-(
Best regards,
Marek Vasut
next prev parent reply other threads:[~2014-04-09 10:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-08 16:12 [PATCH] Add support for flag status register on Micron chips grmoore
2014-04-08 16:12 ` grmoore
2014-04-08 16:12 ` grmoore
2014-04-08 16:12 ` grmoore
2014-04-08 16:52 ` Insop Song
2014-04-08 16:52 ` Insop Song
2014-04-09 10:06 ` Marek Vasut
2014-04-09 10:06 ` Marek Vasut
2014-04-09 10:16 ` Jingoo Han
2014-04-09 10:16 ` Jingoo Han
2014-04-09 10:21 ` Jingoo Han
2014-04-09 10:21 ` Jingoo Han
2014-04-09 10:03 ` Marek Vasut [this message]
2014-04-09 10:03 ` Marek Vasut
2014-04-09 11:09 ` Gerhard Sittig
2014-04-09 11:09 ` Gerhard Sittig
2014-04-09 18:14 ` Graham Moore
2014-04-09 18:14 ` Graham Moore
2014-04-09 18:31 ` Marek Vasut
2014-04-09 18:31 ` Marek Vasut
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=201404091203.24956.marex@denx.de \
--to=marex@denx.de \
--cc=artem.bityutskiy@linux.intel.com \
--cc=atull@altera.com \
--cc=computersforpeace@gmail.com \
--cc=dinguyen@altera.com \
--cc=dwmw2@infradead.org \
--cc=geert+renesas@linux-m68k.org \
--cc=ggrahammoore@gmail.com \
--cc=grmoore@altera.com \
--cc=gsi@denx.de \
--cc=insop.song@gainspeed.com \
--cc=jg1.han@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=rocket.yvanderv@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=sourav.poddar@ti.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.