| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
According to the PPC reference implementation the udelay() function is
responsible for resetting the watchdog timer as frequently as needed.
Most other architectures do not meet that requirement, so long-running
operations might result in a watchdog reset.
This patch adds a generic udelay() function which takes care of
resetting the watchdog before calling an architecture-specific
__udelay().
Signed-off-by: Ingo van Lil <inguin@gmx.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
All arches apparently should reset the watchdog in their udelay loop as
noted on the mailing list recently:
> 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.
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.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The timer_init() function was not using the right csync instruction, nor
was it doing it right after disabling the core timer.
The timer_reset() function would reset the timestamp, but not the actual
timer, so there was a common edge case where get_timer() return a jump of
one timestamp (couple milliseconds) right after resetting. This caused
many functions to improperly timeout right away.
Signed-off-by: Graf Yang <graf.yang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
|
|
All of the duplicated code for Blackfin processors and boot modes have been
unified. After all, the core is the same for all processors, just the
peripheral set differs (which gets handled in the drivers).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
