summaryrefslogtreecommitdiffstats
path: root/drivers/video
diff options
context:
space:
mode:
authorDoug Anderson <dianders@chromium.org>2015-01-27 14:25:16 -0800
committerWim Van Sebroeck <wim@iguana.be>2015-02-17 21:33:43 +0100
commita00850107eb050bf6427a8f3a0445bce9441b5df (patch)
tree65c5862d3d13cfc9b6a44ab0143cc2082e9f66ef /drivers/video
parenta77841d59eb54ceb7b97b5e23053cd205e3a4c00 (diff)
downloadlinux-a00850107eb050bf6427a8f3a0445bce9441b5df.tar.gz
linux-a00850107eb050bf6427a8f3a0445bce9441b5df.tar.bz2
linux-a00850107eb050bf6427a8f3a0445bce9441b5df.zip
watchdog: dw_wdt: pat the watchdog before enabling it
On some dw_wdt implementations the "top" register may be initted to 0 at bootup. In such a case, each "pat" of the watchdog will reset the timer to 0xffff. That's pretty short. The input clock of the wdt can be any of a wide range of values. On an rk3288 system, I've seen the wdt clock be 24.75 MHz. That means each tick is ~40ns and we'll count to 0xffff in ~2.6ms. Because of the above two facts, it's a really good idea to pat the watchdog after initting the "top" register properly and before enabling the watchdog. If you don't then there's no way we'll get the next heartbeat in time. Jisheng Zhang fixed this problem on some dw_wdt versions by using the TOP_INIT feature. However, the dw_wdt on rk3288 doesn't have TOP_INIT so it's a good idea to also pat the watchdog manually. Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Diffstat (limited to 'drivers/video')
0 files changed, 0 insertions, 0 deletions