cfi_cmdset_0002: do_write_buffer timeouts

[Brian Norris]

On Mon, Apr 15, 2013 at 12:55 AM, Huang Shijie <b32955 at freescale.com> wrote:
> 于 2013年04月13日 10:59, Brian Norris 写道:
>
>> Disabling CONFIG_NO_HZ doesn't fix my problem.
>
> I also disable the CONFIG_NO_HZ, and it does not fix my problem too.
>
> But after i remove the mutex_unlock/mutex_lock in
> UDELAY/INVALIDATE_CACHE_UDELAY,
> my problem disappears. I run for three days, no timeout occurs. (I do not
> enable the CONFIG_MTD_XIP).
>
>
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -1043,17 +1043,13 @@ static void __xipram xip_udelay(struct map_info
> *map, struct flchip *chip,
>
> #define UDELAY(map, chip, adr, usec) \
> do { \
> - mutex_unlock(&chip->mutex); \
> cfi_udelay(usec); \
> - mutex_lock(&chip->mutex); \
> } while (0)
>
> #define INVALIDATE_CACHE_UDELAY(map, chip, adr, len, usec) \
> do { \
> - mutex_unlock(&chip->mutex); \
> INVALIDATE_CACHED_RANGE(map, adr, len); \
> cfi_udelay(usec); \
> - mutex_lock(&chip->mutex); \
> } while (0)
>
> #endif

This patch doesn't solve my problem, so it seems that Huang and I
probably are seeing different root causes for these timeouts.

I tried applying this patch and then timing the exact delay seen by
the time we "time out" (by directly accessing the CPU count register),
and the delay is always very close to 4ms (with my kernel, HZ=250, so
4ms is expected). So it seems like my system is waiting plenty long
(according to the flash part specification) but if I wait even longer,
the operation does complete successfully.

I'll continue to look at this issue, but I thought I'd post my results so far.

Brian