[PATCH] mtd: cfi_cmdset_0002: Micron M29EW bugfixes as per TN-13-07

[David Woodhouse]

On Tue, 2012-07-03 at 09:09 +0200, Gerlando Falauto wrote:
> +/*
> + * From TN-13-07: Patching the Linux Kernel and U-Boot for M29 Flash, page 22:
> + *
> + * Some revisions of the M29EW (for example, A1 and A2 step revisions)
> + * are affected by a problem that could cause a hang up when an ERASE SUSPEND
> + * command is issued after an ERASE RESUME operation without waiting for a
> + * minimum delay.  The result is that once the ERASE seems to be completed
> + * (no bits are toggling), the contents of the Flash memory block on which
> + * the erase was ongoing could be inconsistent with the expected values
> + * (typically, the array value is stuck to the 0xC0, 0xC4, 0x80, or 0x84
> + * values), causing a consequent failure of the ERASE operation.
> + * The occurrence of this issue could be high, especially when file system
> + * operations on the Flash are intensive.  As a result, it is recommended
> + * that a patch be applied.  Intensive file system operations can cause many
> + * calls to the garbage routine to free Flash space (also by erasing physical
> + * Flash blocks) and as a result, many consecutive SUSPEND and RESUME
> + * commands can occur.  The problem disappears when a delay is inserted after
> + * the RESUME command by using the udelay() function available in Linux.
> + * The DELAY value must be tuned based on the customer's platform.
> + * The maximum value that fixes the problem in all cases is 500us.
> + * But, in our experience, a delay of 30 us to 50 us is sufficient
> + * in most cases.
> + * We have chosen 500us because this latency is acceptable.
> + */
> +static void cfi_fixup_m29ew_delay_after_resume(struct cfi_private *cfi)
> +{
> +       /*
> +        * Resolving the Delay After Resume Issue see Micron TN-13-07
> +        * Worstcase delay must be 500us but 30-50us should be ok as well
> +        */
> +       if (is_m29ew(cfi))
> +               cfi_udelay(500);
> +}

Hm, this would be better off done without a hard delay right there, but
instead just note the timestamp. Then use your existing hook in erase
suspend to check that it's been long enough since the last resume, and
have a *conditional* delay if not.

This assumes you have a timer with enough precision, of course.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130212/2d8f5fc1/attachment.bin>