nand commands missing wtchdog reset

Hi all,
On my board (at91sam9263ek) I have enabled the watchdog.
It will reset the processor after about 16 seconds.
It looks like it is working but if I'm writing a large file into nand it seems that the watchdog is not reset and finally my processor resets. I've patched it, but I'm not sure if it is the right way to do it this way...

diff -urN a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c

drivers/mtd/nand/nand_base.c 2011-01-31 08:45:07.818135600 +0100 renamed from drivers/mtd/nand/nand_base.c 2010-12-22 20:22:14.000000000 +0100 +1 -0

@@ -447,6 +447,7 @@
          if (chip->dev_ready)
              if (chip->dev_ready(mtd))
                  break;
+        WATCHDOG_RESET ();
      }
  }
 

Quoted 7 lines · On Mon, 31 Jan 2011 09:05:55 +0100 Jaap de Jong <[email protected]> wrote:

Hi all,
On my board (at91sam9263ek) I have enabled the watchdog.
It will reset the processor after about 16 seconds.
It looks like it is working but if I'm writing a large file into nand it seems that the watchdog is not reset and finally my processor resets. I've patched it, but I'm not sure if it is the right way to do it this way...

So far we've been putting the watchdog resets in higher-level functions. It looks like the block-skipping versions have them, but the non-block-skipping versions don't (and the former will call the latter if it doesn't see any bad blocks).

So I think this should go in nand_read() and nand_write(). If things hang up inside the low-level wait that should trigger the watchdog.

Quoted 10 lines · On Mon, 31 Jan 2011 13:16:59 -0600 Scott Wood<[email protected]> wrote:

Quoted 7 lines · On Mon, 31 Jan 2011 09:05:55 +0100 Jaap de Jong<[email protected]> wrote:

Hi all,
On my board (at91sam9263ek) I have enabled the watchdog.
It will reset the processor after about 16 seconds.
It looks like it is working but if I'm writing a large file into nand it seems that the watchdog is not reset and finally my processor resets. I've patched it, but I'm not sure if it is the right way to do it this way...

Quoted 7 lines

So far we've been putting the watchdog resets in higher-level functions. It looks like the block-skipping versions have them, but the non-block-skipping versions don't (and the former will call the latter if it doesn't see any bad blocks).

So I think this should go in nand_read() and nand_write(). If things hang up inside the low-level wait that should trigger the watchdog.

Oh, and all patches require a sign-off, and the text above the patch should be what is intended to go in the git changelog, with any additional comments/greetings/etc below a "---" line.

See http://www.denx.de/wiki/U-Boot/Patches
and also the Developer's Certificate of Origin in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD

-Scott

thanks for your reply.
You are right, the format was totally wrong; I apologize! Concerning the patch itself: I agree: low-level hangups should trigger the watchdog although in this specific case the hangups will not occur due to a timeout construction surrounding it.

Unfortunately I'm not able to investigate this any further
To get this fix done: hopefully some u-boot-guru will do the dirty work...