[PATCH] mtd: cfi_cmdset_0001 - fixup for PC28F512P33TFA

[Joakim Tjernlund]

Joakim Tjernlund/Transmode wrote on 2014/04/01 10:29:43:
> 
> Christoph Fritz <chf.fritz at googlemail.com> wrote on 2014/04/01 00:04:20:
> > 
> > On Mon, 2014-03-31 at 22:31 +0200, Joakim Tjernlund wrote:
> > > No way, disabling erase suspend will cause severe latencies for 
read/write 
> > > ops.
> > 
> > Here on a mx35 it's not really severe.
> 
> 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.
> 
> > 
> > > 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

 Jocke

 Jocke