forked from Minki/linux
watchdog: imgpdc: Add some documentation about the timeout
This watchdog hardware can be configured in terms of power-of-two clock cycles. Therefore, the watchdog timeout configured by the user will be rounded-up to the next possible hardware timeout. This commit adds a comment explaining this. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@imgtec.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
This commit is contained in:
parent
deb8d50eb4
commit
c1f263878e
@ -9,6 +9,35 @@
|
||||
*
|
||||
* Based on drivers/watchdog/sunxi_wdt.c Copyright (c) 2013 Carlo Caione
|
||||
* 2012 Henrik Nordstrom
|
||||
*
|
||||
* Notes
|
||||
* -----
|
||||
* The timeout value is rounded to the next power of two clock cycles.
|
||||
* This is configured using the PDC_WDT_CONFIG register, according to this
|
||||
* formula:
|
||||
*
|
||||
* timeout = 2^(delay + 1) clock cycles
|
||||
*
|
||||
* Where 'delay' is the value written in PDC_WDT_CONFIG register.
|
||||
*
|
||||
* Therefore, the hardware only allows to program watchdog timeouts, expressed
|
||||
* as a power of two number of watchdog clock cycles. The current implementation
|
||||
* guarantees that the actual watchdog timeout will be _at least_ the value
|
||||
* programmed in the imgpdg_wdt driver.
|
||||
*
|
||||
* The following table shows how the user-configured timeout relates
|
||||
* to the actual hardware timeout (watchdog clock @ 40000 Hz):
|
||||
*
|
||||
* input timeout | WD_DELAY | actual timeout
|
||||
* -----------------------------------
|
||||
* 10 | 18 | 13 seconds
|
||||
* 20 | 19 | 26 seconds
|
||||
* 30 | 20 | 52 seconds
|
||||
* 60 | 21 | 104 seconds
|
||||
*
|
||||
* Albeit coarse, this granularity would suffice most watchdog uses.
|
||||
* If the platform allows it, the user should be able to change the watchdog
|
||||
* clock rate and achieve a finer timeout granularity.
|
||||
*/
|
||||
|
||||
#include <linux/clk.h>
|
||||
|
Loading…
Reference in New Issue
Block a user