* [PATCH v3 2/2] watchdog: dw_wdt: Try to get a 30 second watchdog by default
2015-01-27 22:25 [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it Doug Anderson
@ 2015-01-27 22:25 ` Doug Anderson
2015-02-03 19:02 ` Wim Van Sebroeck
2015-01-28 1:38 ` [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it Jisheng Zhang
` (2 subsequent siblings)
3 siblings, 1 reply; 6+ messages in thread
From: Doug Anderson @ 2015-01-27 22:25 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Heiko Stuebner, Lunxue Dai, Jisheng Zhang, Dinh Nguyen,
Doug Anderson, linux-watchdog, linux-kernel
The dw_wdt_set_top() function takes in a value in seconds. In
dw_wdt_open() we were calling it with a value that's supposed to
represent the maximum value programmed into the "top" register with a
comment saying that we were trying to set the watchdog to its maximum
value. Instead we ended up setting the watchdog to ~15 seconds.
Let's fix this. However, setting things to the "max" gives me an 86
second watchdog in the system I'm looking at. 86 seconds feels a
little too long. We'll explicitly choose 30 seconds as a more
reasonable value.
NOTE: Ideally this driver should be transitioned to be a real watchdog
driver. Then we could use "watchdog_init_timeout" and let the timeout
be specified in a number of ways (device tree, module parameter, etc).
This patch should be considered a bit of a stopgap solution.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
---
Changes in v3: None
Changes in v2: None
drivers/watchdog/dw_wdt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 3dde6de..d0bb949 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -51,6 +51,8 @@
/* The maximum TOP (timeout period) value that can be set in the watchdog. */
#define DW_WDT_MAX_TOP 15
+#define DW_WDT_DEFAULT_SECONDS 30
+
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
@@ -179,9 +181,9 @@ static int dw_wdt_open(struct inode *inode, struct file *filp)
if (!dw_wdt_is_enabled()) {
/*
* The watchdog is not currently enabled. Set the timeout to
- * the maximum and then start it.
+ * something reasonable and then start it.
*/
- dw_wdt_set_top(DW_WDT_MAX_TOP);
+ dw_wdt_set_top(DW_WDT_DEFAULT_SECONDS);
writel(WDOG_CONTROL_REG_WDT_EN_MASK,
dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v3 2/2] watchdog: dw_wdt: Try to get a 30 second watchdog by default
2015-01-27 22:25 ` [PATCH v3 2/2] watchdog: dw_wdt: Try to get a 30 second watchdog by default Doug Anderson
@ 2015-02-03 19:02 ` Wim Van Sebroeck
0 siblings, 0 replies; 6+ messages in thread
From: Wim Van Sebroeck @ 2015-02-03 19:02 UTC (permalink / raw)
To: Doug Anderson
Cc: Guenter Roeck, Heiko Stuebner, Lunxue Dai, Jisheng Zhang,
Dinh Nguyen, linux-watchdog, linux-kernel
Hi Doug,
> The dw_wdt_set_top() function takes in a value in seconds. In
> dw_wdt_open() we were calling it with a value that's supposed to
> represent the maximum value programmed into the "top" register with a
> comment saying that we were trying to set the watchdog to its maximum
> value. Instead we ended up setting the watchdog to ~15 seconds.
>
> Let's fix this. However, setting things to the "max" gives me an 86
> second watchdog in the system I'm looking at. 86 seconds feels a
> little too long. We'll explicitly choose 30 seconds as a more
> reasonable value.
>
> NOTE: Ideally this driver should be transitioned to be a real watchdog
> driver. Then we could use "watchdog_init_timeout" and let the timeout
> be specified in a number of ways (device tree, module parameter, etc).
> This patch should be considered a bit of a stopgap solution.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
This one has also been added to linux-watchdog-next.
Kind regards,
Wim.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
2015-01-27 22:25 [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it Doug Anderson
2015-01-27 22:25 ` [PATCH v3 2/2] watchdog: dw_wdt: Try to get a 30 second watchdog by default Doug Anderson
@ 2015-01-28 1:38 ` Jisheng Zhang
2015-01-28 18:58 ` Guenter Roeck
2015-02-03 19:01 ` Wim Van Sebroeck
3 siblings, 0 replies; 6+ messages in thread
From: Jisheng Zhang @ 2015-01-28 1:38 UTC (permalink / raw)
To: Doug Anderson
Cc: Wim Van Sebroeck, Guenter Roeck, Heiko Stuebner, Lunxue Dai,
Dinh Nguyen, linux-watchdog, linux-kernel
On Tue, 27 Jan 2015 14:25:16 -0800
Doug Anderson <dianders@chromium.org> wrote:
> 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>
> ---
> Changes in v3:
> - Better comments now that we know what's going on.
> - Don't typo dw_wdt as dw_mmc.
>
> Changes in v2:
> - Add comment about why TOP_INIT doesn't work on rk3288; move pat
> to right next to the attempt to use TOP_INIT.
>
> drivers/watchdog/dw_wdt.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
> index b34a2e4..3dde6de 100644
> --- a/drivers/watchdog/dw_wdt.c
> +++ b/drivers/watchdog/dw_wdt.c
> @@ -96,6 +96,12 @@ static inline void dw_wdt_set_next_heartbeat(void)
> dw_wdt.next_heartbeat = jiffies + dw_wdt_get_top() * HZ;
> }
>
> +static void dw_wdt_keepalive(void)
> +{
> + writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
> + WDOG_COUNTER_RESTART_REG_OFFSET);
> +}
> +
> static int dw_wdt_set_top(unsigned top_s)
> {
> int i, top_val = DW_WDT_MAX_TOP;
> @@ -110,21 +116,27 @@ static int dw_wdt_set_top(unsigned top_s)
> break;
> }
>
> - /* Set the new value in the watchdog. */
> + /*
> + * Set the new value in the watchdog. Some versions of dw_wdt
> + * have have TOPINIT in the TIMEOUT_RANGE register (as per
> + * CP_WDT_DUAL_TOP in WDT_COMP_PARAMS_1). On those we
> + * effectively get a pat of the watchdog right here.
> + */
> writel(top_val | top_val << WDOG_TIMEOUT_RANGE_TOPINIT_SHIFT,
> dw_wdt.regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
>
> + /*
> + * Add an explicit pat to handle versions of the watchdog that
> + * don't have TOPINIT. This won't hurt on versions that have
> + * it.
> + */
> + dw_wdt_keepalive();
> +
> dw_wdt_set_next_heartbeat();
>
> return dw_wdt_top_in_seconds(top_val);
> }
>
> -static void dw_wdt_keepalive(void)
> -{
> - writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
> - WDOG_COUNTER_RESTART_REG_OFFSET);
> -}
> -
> static int dw_wdt_restart_handle(struct notifier_block *this,
> unsigned long mode, void *cmd)
> {
Looks good to me
Thanks
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
2015-01-27 22:25 [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it Doug Anderson
2015-01-27 22:25 ` [PATCH v3 2/2] watchdog: dw_wdt: Try to get a 30 second watchdog by default Doug Anderson
2015-01-28 1:38 ` [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it Jisheng Zhang
@ 2015-01-28 18:58 ` Guenter Roeck
2015-02-03 19:01 ` Wim Van Sebroeck
3 siblings, 0 replies; 6+ messages in thread
From: Guenter Roeck @ 2015-01-28 18:58 UTC (permalink / raw)
To: Doug Anderson
Cc: Wim Van Sebroeck, Heiko Stuebner, Lunxue Dai, Jisheng Zhang,
Dinh Nguyen, linux-watchdog, linux-kernel
On Tue, Jan 27, 2015 at 02:25:16PM -0800, Doug Anderson wrote:
> 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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
2015-01-27 22:25 [PATCH v3 1/2] watchdog: dw_wdt: pat the watchdog before enabling it Doug Anderson
` (2 preceding siblings ...)
2015-01-28 18:58 ` Guenter Roeck
@ 2015-02-03 19:01 ` Wim Van Sebroeck
3 siblings, 0 replies; 6+ messages in thread
From: Wim Van Sebroeck @ 2015-02-03 19:01 UTC (permalink / raw)
To: Doug Anderson
Cc: Guenter Roeck, Heiko Stuebner, Lunxue Dai, Jisheng Zhang,
Dinh Nguyen, linux-watchdog, linux-kernel
Hi Doug,
> 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>
Patch has been added to linux-watchdog-next.
Kind regards,
Wim.
^ permalink raw reply [flat|nested] 6+ messages in thread