diff mbox

[U-Boot] watchdog/imx_watchdog: do not set WCR_WDW

Message ID 1425401143-2647-1-git-send-email-bigeasy@linutronix.de
State Awaiting Upstream
Delegated to: Stefano Babic
Headers show

Commit Message

Sebastian Andrzej Siewior March 3, 2015, 4:45 p.m. UTC
with WCR_WDW set, the watchdog won't trigger if we bootet linux and idle
around while the watchdog is not triggered. It seems the timer makes
progress very slowly if at all. I managed to remain 20minutes alive
while the timeout was set to 60secs. It reboots within 60secs if I start
a busyloop in userland (something like "while (1) { }").

While I don't see a reason why the WDT should not be running while the
CPU is in idle, I'm dropping this bit.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 drivers/watchdog/imx_watchdog.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

Stefano Babic March 25, 2015, 8:03 a.m. UTC | #1
Hi Sebastian,

(sorry for late answer)

On 03/03/2015 17:45, Sebastian Andrzej Siewior wrote:
> with WCR_WDW set, the watchdog won't trigger if we bootet linux and idle
> around while the watchdog is not triggered. It seems the timer makes
> progress very slowly if at all. I managed to remain 20minutes alive
> while the timeout was set to 60secs. It reboots within 60secs if I start
> a busyloop in userland (something like "while (1) { }").

Just some questions. The described behavior is coherent with the
description in the manual. When WDW is set, the watchdog is stopped
while the processor is in wait mode.
Current imx2_wdt.c driver in kernel does not care about this bit, but it
looks like that only the kernel and/or the application can decide if the
watchdog should run when the system is in WAIT or not. The bootloader
cannot decide, and it should set the bit for its own usage.

Should this setup be done by the kernel driver instead of by the
bootloader ?

> 
> While I don't see a reason why the WDT should not be running while the
> CPU is in idle, I'm dropping this bit.

I can agree or disagree. This depends on the application.

Differently as the WDZST, that can be set only once, and it is set by
*both* U-Boot and kernel (setting in kernel has then no influence), the
WDW can be even disabled in kernel.

> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  drivers/watchdog/imx_watchdog.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
> index d5993b4d26d6..1d18d4b269f8 100644
> --- a/drivers/watchdog/imx_watchdog.c
> +++ b/drivers/watchdog/imx_watchdog.c
> @@ -20,7 +20,6 @@ struct watchdog_regs {
>  #define WCR_WDE		0x04	/* WDOG enable */
>  #define WCR_WDT		0x08
>  #define WCR_SRS		0x10
> -#define WCR_WDW		0x80
>  #define SET_WCR_WT(x)	(x << 8)
>  
>  #ifdef CONFIG_IMX_WATCHDOG
> @@ -47,7 +46,7 @@ void hw_watchdog_init(void)
>  #endif
>  	timeout = (CONFIG_WATCHDOG_TIMEOUT_MSECS / 500) - 1;
>  	writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
> -		WCR_WDW | SET_WCR_WT(timeout), &wdog->wcr);
> +		SET_WCR_WT(timeout), &wdog->wcr);
>  	hw_watchdog_reset();
>  }
>  #endif
> 

Best regards,
Stefano Babic
Sebastian Andrzej Siewior March 25, 2015, 12:15 p.m. UTC | #2
* Stefano Babic | 2015-03-25 09:03:06 [+0100]:

>Hi Sebastian,
Hi Stefano,

>(sorry for late answer)
no worries.

>On 03/03/2015 17:45, Sebastian Andrzej Siewior wrote:
>> with WCR_WDW set, the watchdog won't trigger if we bootet linux and idle
>> around while the watchdog is not triggered. It seems the timer makes
>> progress very slowly if at all. I managed to remain 20minutes alive
>> while the timeout was set to 60secs. It reboots within 60secs if I start
>> a busyloop in userland (something like "while (1) { }").
>
>Just some questions. The described behavior is coherent with the
>description in the manual. When WDW is set, the watchdog is stopped
>while the processor is in wait mode.

I fail to notice how it could make any sense.

>Current imx2_wdt.c driver in kernel does not care about this bit, but it
>looks like that only the kernel and/or the application can decide if the
>watchdog should run when the system is in WAIT or not. The bootloader
>cannot decide, and it should set the bit for its own usage.
>
>Should this setup be done by the kernel driver instead of by the
>bootloader ?

It is a one-time-bit. Once it is set (or not) it can not be changed
later. It makes no difference for the bootloader. And the kernel may
remain idle for longer than one jiffy with NO_HZ but it will still wake
up within a second if I remember correctly. Eitherway the user will
usually trigger the WD in timeout/2 so atleast that timer will wake up
the kernel from idle.
Having the WDT not account the idle time makes it hard for the user to
figure out how much time has been accounted by the WDT so far.

>> 
>> While I don't see a reason why the WDT should not be running while the
>> CPU is in idle, I'm dropping this bit.
>
>I can agree or disagree. This depends on the application.
>
>Differently as the WDZST, that can be set only once, and it is set by
>*both* U-Boot and kernel (setting in kernel has then no influence), the
>WDW can be even disabled in kernel.

I patched the kernel as well. Once I get through here I would also push
patches there. The thing I don't like is that the kernel pings the WDT
on its own. While it may make sense for some people I would like to
atleast configure it :)

Sebastian
Stefano Babic March 25, 2015, 1:08 p.m. UTC | #3
Hi Sebastian,

On 25/03/2015 13:15, Sebastian Andrzej Siewior wrote:

>>
>> Just some questions. The described behavior is coherent with the
>> description in the manual. When WDW is set, the watchdog is stopped
>> while the processor is in wait mode.
> 
> I fail to notice how it could make any sense.

Well, I have not said it makes sense - only that the behavior is
expected ;-)

> 
>> Current imx2_wdt.c driver in kernel does not care about this bit, but it
>> looks like that only the kernel and/or the application can decide if the
>> watchdog should run when the system is in WAIT or not. The bootloader
>> cannot decide, and it should set the bit for its own usage.
>>
>> Should this setup be done by the kernel driver instead of by the
>> bootloader ?
> 
> It is a one-time-bit. Once it is set (or not) it can not be changed
> later. It makes no difference for the bootloader.

mmhhh..Sorry, it looks like I read the wrong line in the manual. This is
a write once bit exactly as WDZST. My assumption were wrong. We cannot
disable in kernel if the bootloader has already activated it.

> And the kernel may
> remain idle for longer than one jiffy with NO_HZ but it will still wake
> up within a second if I remember correctly. Eitherway the user will
> usually trigger the WD in timeout/2 so atleast that timer will wake up
> the kernel from idle.
> Having the WDT not account the idle time makes it hard for the user to
> figure out how much time has been accounted by the WDT so far.

I have no objections here - I start from the wrong assumption that the
bit could be cleared by the kernel, but it is not.

> 
>>>
>>> While I don't see a reason why the WDT should not be running while the
>>> CPU is in idle, I'm dropping this bit.
>>
>> I can agree or disagree. This depends on the application.
>>
>> Differently as the WDZST, that can be set only once, and it is set by
>> *both* U-Boot and kernel (setting in kernel has then no influence), the
>> WDW can be even disabled in kernel.
> 
> I patched the kernel as well. Once I get through here I would also push
> patches there. The thing I don't like is that the kernel pings the WDT
> on its own. While it may make sense for some people I would like to
> atleast configure it :)

Agree, patch put in my merge queue.

Acked-by: Stefano Babic <sbabic@denx.de>

Best regards,
Stefano
Stefano Babic March 25, 2015, 3:53 p.m. UTC | #4
On 03/03/2015 17:45, Sebastian Andrzej Siewior wrote:
> with WCR_WDW set, the watchdog won't trigger if we bootet linux and idle
> around while the watchdog is not triggered. It seems the timer makes
> progress very slowly if at all. I managed to remain 20minutes alive
> while the timeout was set to 60secs. It reboots within 60secs if I start
> a busyloop in userland (something like "while (1) { }").
> 
> While I don't see a reason why the WDT should not be running while the
> CPU is in idle, I'm dropping this bit.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic
Sebastian Andrzej Siewior March 26, 2015, 8:02 a.m. UTC | #5
On 03/25/2015 04:53 PM, Stefano Babic wrote:
> On 03/03/2015 17:45, Sebastian Andrzej Siewior wrote:
>> with WCR_WDW set, the watchdog won't trigger if we bootet linux and idle
>> around while the watchdog is not triggered. It seems the timer makes
>> progress very slowly if at all. I managed to remain 20minutes alive
>> while the timeout was set to 60secs. It reboots within 60secs if I start
>> a busyloop in userland (something like "while (1) { }").
>>
>> While I don't see a reason why the WDT should not be running while the
>> CPU is in idle, I'm dropping this bit.
>>
>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> ---
> 
> Applied to u-boot-imx, thanks !

Thanks. What just came to mind: In case you do suspend-to-mem. Would
the watchdog trigger then? I am not sure and I have no way to test…

> Best regards,
> Stefano Babic

Sebastian
Stefano Babic March 26, 2015, 8:27 a.m. UTC | #6
Hi Sebastian,

On 26/03/2015 09:02, Sebastian Andrzej Siewior wrote:
> On 03/25/2015 04:53 PM, Stefano Babic wrote:
>> On 03/03/2015 17:45, Sebastian Andrzej Siewior wrote:
>>> with WCR_WDW set, the watchdog won't trigger if we bootet linux and idle
>>> around while the watchdog is not triggered. It seems the timer makes
>>> progress very slowly if at all. I managed to remain 20minutes alive
>>> while the timeout was set to 60secs. It reboots within 60secs if I start
>>> a busyloop in userland (something like "while (1) { }").
>>>
>>> While I don't see a reason why the WDT should not be running while the
>>> CPU is in idle, I'm dropping this bit.
>>>
>>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>>> ---
>>
>> Applied to u-boot-imx, thanks !
> 
> Thanks. What just came to mind: In case you do suspend-to-mem. Would
> the watchdog trigger then? I am not sure and I have no way to test…

I have also not tested, but in my understanding this is ruled by the
WDZST. This is also a write-once bit, and suspend the watchdog timer
during low power modes.

Best regards,
Stefano Babic
diff mbox

Patch

diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
index d5993b4d26d6..1d18d4b269f8 100644
--- a/drivers/watchdog/imx_watchdog.c
+++ b/drivers/watchdog/imx_watchdog.c
@@ -20,7 +20,6 @@  struct watchdog_regs {
 #define WCR_WDE		0x04	/* WDOG enable */
 #define WCR_WDT		0x08
 #define WCR_SRS		0x10
-#define WCR_WDW		0x80
 #define SET_WCR_WT(x)	(x << 8)
 
 #ifdef CONFIG_IMX_WATCHDOG
@@ -47,7 +46,7 @@  void hw_watchdog_init(void)
 #endif
 	timeout = (CONFIG_WATCHDOG_TIMEOUT_MSECS / 500) - 1;
 	writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
-		WCR_WDW | SET_WCR_WT(timeout), &wdog->wcr);
+		SET_WCR_WT(timeout), &wdog->wcr);
 	hw_watchdog_reset();
 }
 #endif