| Message ID | 516BB279.9000000@freescale.com |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Apr 15, 2013 at 12:55 AM, Huang Shijie <b32955@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
于 2013年04月18日 05:45, Brian Norris 写道: > This patch doesn't solve my problem, so it seems that Huang and I > probably are seeing different root causes for these timeouts. > yes. My timeout maybe caused by the error in the erase-suspend/erase-resume. thanks Huang Shijie
--- 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)
于 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). #endif