Re: [PATCH] mtd: cfi_cmdset_0001 - fixup for PC28F512P33TFA

[Christoph Fritz <chf.fritz@googlemail.com>]

Hi Joakim,

 thanks for your input, please see my further comments below.

On Tue, 2014-04-01 at 13:15 +0200, Joakim Tjernlund wrote:
> > There has been complaints in the past with no erase suspend.
> > You get delays considering that an erase takes c.a 1 sek so
> > once you get into a state where GC is erasing lots of blocks and other
> > progs wants read/write you will notice.

Yes it's not a fine solution, it's a quirk for a hardware with issues.
But here for me it's better to get delays than having to suffer from
flash errors.

> > > > The document mentions other ways to get around this problem, I 
> suggest you 
> > > > explore
> > > > these first.
> > > 
> > > Already tried the “0xFF” dummy write cycle suggestion, should have
> > > mentioned that.
> > 
> > OK, but one more workaround(the udelay part) is required, right?
> 
> There something odd with the patches in the mentioned doc.
> 1) "Resolving ERASE SUSPEND Hangups" touches the same code as
> 2) "ERASE SUSPEND Following ERASE RESUME"
> 
> 1) says to add write(0xff) and 2) adds a udelay
> 
> What should it be, both? in what order?
> 
> I suspect that any write(0xff) can be there unconditionally, provided that 
> the cmd0001 spec allows it.
> The delay could be a quirk default to 0

I already tried all sorts of combinations of various delays and 0xff
writes, which can be used wasteful without impact. And yes, errors are
happening less -- but are still happening (at for example -2°C starting
udev or a filesys-bench program like bonnie++).

Sure, it's possible that I missed the holy right
delay-0xff-quirk-combination to get this NOR flash reliable working for
its specified temperature range. But until nobody has found it, I would
prefer to stick to my posted quirk and just disable suspend erase.

Maybe someone from Micron can help?

 Thanks
  -- Christoph