Re: [PATCH] Add support for flag status register on Micron chips

[Graham Moore]

On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig <gsi@xxxxxxx> wrote:
> On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote:
>>
>> On Tuesday, April 08, 2014 at 06:12:49 PM, grmoore@xxxxxxxxxx wrote:
>> > From: Graham Moore <grmoore@xxxxxxxxxx>
>> >
>> > 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.
[...]
>> > 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.
>
> This sounds to me similar to polling the NAND's R/B pin until the
> operation has completed, to then fetch the STATUS byte to
> determine the execution's result.  Does this sound plausible?
> For NOR, do you poll for the "busy" condition to deassert, and
> check for success then?

Sounds plausible to me.  We poll the SR until not busy, then poll the
FSR until it's not busy.  Success is when FSR busy is deasserted
within the timeout.

Micron said we have to read the FSR "at least once", so we don't
read it once for every die or anything like that.  I ran a quick
test, and for both the 2-die and 4-die parts, the FSR shows not busy
on the first read after SR not busy.

-Graham
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/