Renato Andreola wrote:
From 21d84ab72266f118794233176bd356d8b1cfdf35 Mon Sep 17 00:00:00 2001 From: Renato Andreola renato.andreola@imagos.it Date: Fri, 21 Aug 2009 18:05:51 +0200 Subject: [PATCH] drivers/mtd/cfi_flash: precision and underflow problem in tout calculation
With old configuration it could happen tout=0 if CONFIG_SYS_HZ<1000.
Signed-off-by: Alessandro Rubini rubini@gnudd.com Renato Andreola renato.andreola@imagos.it
drivers/mtd/cfi_flash.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index 81ac5d3..0d8fc54 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -660,9 +660,11 @@ static int flash_status_check (flash_info_t * info, flash_sect_t sector, ulong start;
#if CONFIG_SYS_HZ != 1000
- tout *= CONFIG_SYS_HZ/1000;
-#endif
- if ((ulong)CONFIG_SYS_HZ > 100000)
tout *= (ulong)CONFIG_SYS_HZ/1000; /* for a big HZ, avoid overflow */- else
tout = DIV_ROUND_UP(tout*(ulong)CONFIG_SYS_HZ, 1000);+#endif /* Wait for command completion */ start = get_timer (0); while (flash_is_busy (info, sector)) {
What should to be fixed first in this case, would be your CONFIG_SYS_HZ setting, that is NIOS2? timer implementation, yeah really. But I would also point out that there is another case flash_status_check() doensn't work as expected.
One of my colleagues found that with some flash device(s) (I don't recall precisely, sorry), 'tout' would be probed to be zero. In that case, a workaround something like above still doesn't work.
We have not sorted out where the problem is; it might be in cfi_flash.c, or in the flash device itself. This is observed with v2009.03 release, and we've been having a workaround for it for months. I'd like to have a look someday.
Anyway, checking to see if 'tout' is zero or not would be sometimes worth a try, when you think cfi_flash.c doesn't work as expected.
Just for your information,