From: J. William Campbell <jwilliamcampbell@comcast.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Date: Fri, 02 Oct 2009 13:21:55 -0700 [thread overview]
Message-ID: <4AC660E3.4010404@comcast.net> (raw)
In-Reply-To: <200910021431.23079.vapier@gentoo.org>
Mike Frysinger wrote:
> On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote:
>
>> Ingo van Lil wrote:
>>
>>> The CFI driver does not reset the device's watchdog, so long-running
>>> flash operations will cause the watchdog timer to expire. A comment in
>>> flash_status_check() suggests that udelay() is expected to reset the
>>> watchdog, but I can't find any architecture where it does.
>>>
>> Please have a closer look, then. On PowerPC, udelay()
>> ["lib_ppc/time.c"] calls wait_ticks(), which in turn
>> ["lib_ppc/ticks.S"] calls WATCHDOG_RESET
>>
>> If this is missing in other architectures, it should be fixed at the
>> root cause, i. e. in udelay() or in the respective support routines.
>>
>
> Blackfin is missing it as well as i really had no idea it was supposed to be
> there. certainly no doc states this requirement. perhaps it'd make sense to
> break apart the common stuff to a common udelay() that does things like call
> the watchdog and then call the implementation __udelay(). there should be at
> least a doc/README.arch that includes these kind of details ...
> -mike
>
>
At this point it might be appropriate to ask if including such a reset
in udelay() is a good idea. The way it is, no "infinite loop" in u-boot
that contains a udelay() will ever allow the watchdog to time out. That
restriction is somewhat non-obvious. I would argue that there are
basically two classes of commands in u-boot, those that should execute
so fast that there is no way the watchdog should be triggered, and
commands that may take "a long time" during which the watchdog may
erroneously be triggered if there is no provision made to reset it. In
the second case, the resetting of the watchdog must be placed where
"measurable progress" towards command completion is being made, i.e.
there is a certainty that we are getting closer to a command complete.
Just because the program invokes udelay, there is no assurance that
measurable progress is being made. The udelay may be part of a process
that will never complete. Therefore, having a watchdog reset in udelay
seems like a less than optimal idea in general. Maybe now would be a
good time to look at removing it?
Bill Campbell
> ------------------------------------------------------------------------
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
next prev parent reply other threads:[~2009-10-02 20:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 10:34 [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation Ingo van Lil
2009-10-02 11:06 ` Stefan Roese
2009-10-02 12:12 ` Ingo van Lil
2009-10-03 23:29 ` Wolfgang Denk
2009-10-04 11:15 ` Ingo van Lil
2009-10-04 11:49 ` Graeme Russ
2009-10-02 12:30 ` Wolfgang Denk
2009-10-02 18:31 ` Mike Frysinger
2009-10-02 19:35 ` Wolfgang Denk
2009-10-02 20:21 ` J. William Campbell [this message]
2009-10-02 21:59 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AC660E3.4010404@comcast.net \
--to=jwilliamcampbell@comcast.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox