linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jiri.prchal@aksignal.cz (Jiří Prchal)
To: linux-arm-kernel@lists.infradead.org
Subject: at91sam9: watchdog: period
Date: Wed, 7 Oct 2015 09:16:52 +0200	[thread overview]
Message-ID: <5614C6E4.20808@aksignal.cz> (raw)
In-Reply-To: <20151006180342.GA13434@gradator.net>

Thanks Sylvain,
good explanation, now it's clear for me.
It works!
The problem is SOLVED!

On 6.10.2015 20:03, Sylvain Rochet wrote:
> Hi Ji??,
>
> On Fri, May 15, 2015 at 09:16:37AM +0200, Ji?? Prchal wrote:
>> Hi all,
>> I'm trying to discover what's wrong with watchdog on my board. I didn't find
>> anything about it on internet so I would ask you for help.
>> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors
>> to GND. Frequency seems to be good since hwclock (RTC) runs pretty precisely
>> powered from backup and main power too (no NTP). But watchdog time to reset
>> is still 61s regardless default (16s) or 4s heartbeat setting. No change to
>> WDT_MR in bootstrap, so in Linux should work.
>
> I'm a bit late here but it looks like there is a misunderstanding about
> the watchdog stack involved here:
>
> userland
> ------- /dev/watchdog0 ------
> watchdog0
>    -> userland wanted reset time value
>    -> userland wanted ping time value
> ------- internal kernel watchdog interface ------
> atmel,at91sam9260-wdt
>    -> atmel,min-heartbeat-sec
>    -> atmel,max-heartbeat-sec
>
> watchdog0 is the software interface, controlled by your userland, is it
> always on top of the hardware watchdog and it calls the watchdog_ops
> hooks, like watchdog_ops->start(), watchdog_ops->stop(), or
> watchdog_ops->set_timeout() for this driver depending on the userland
> willingness to (re)start, stop the watchdog or change the hardware
> timeout value.
>
> watchdog0 have two configurable values, reset time and ping time, the
> default is 60s for timeout and 30s for ping (the 61s you are
> seeing is the default timeout value).
>
> For example, the watchdog binary from BusyBox allows you to set the
> watchdog0 reset and ping time using -T and -t arguments:
>      -T N    Reboot after N seconds if not reset (default 60)
>      -t N    Reset every N seconds (default 30)
>
> The -T value is sent to the hardware driver using the
> watchdog_ops->set_timeout() hook. The -t value is how often you want the
> watchdog to be (re)started using the watchdog_ops->start() hook.
>
> In a perfect world, the watchdog_ops->set_timeout() hook should be able
> to precisely set the hardware timeout you want, but there is two
> problems here:
>
>    - 60 secs timeout is more than supported by this hardware watchdog,
> which have a maximum timeout value of 16 secs. The driver is able to
> return to userland that wanted values are not acceptable, but it would
> means the default watchdog values wouldn't work.
>
>    - This hardware watchdog is a bit special: its period cannot be
> changed once started, usually the hardware timeout follows the watchdog0
> timeout value wanted by userspace but that's not possible here. That's
> why this driver is using its own heartbeat software timer to reset the
> hardware watchdog more often than actually asked by userland. Thus,
> because we are resetting on your own the hardware watchdog it means that
> once the software watchdog embedded into this driver expire there is
> still the hardware watchdog to expire.
>
> We try to reset the watchdog counter 4 or 2 times more often than
> actually requested, in order to avoid spurious watchdog reset. For the 4
> times case (the default), we get a hardware timeout between 12 and 16
> secs.
>
> Conclusion, if you want a fast reset, you have to use a lower
> atmel,max-heartbeat-sec value as well as using low values for the
> timeouts values passed to kernel through the watchdog interface
> "watchdog -T -t".
>
> I wonder if we should substract from the watchdog_ops->set_timeout()
> new_timeout argument value the previously set hardware timeout period,
> this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16"
> watchdog timeout. If someone agree I will propose a patch to do that.
>
>
>> / # killall watchdog
>> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
>> [ 1821.123123] watchdog watchdog0: watchdog did not stop!
>
> 60 seconds software timeout, this is the default set by userland tools.
>
>> [ 1882.294294] at91sam9_wdt: I will reset your machine !
>
> Then 12 to 16 seconds timeout, this is the hardware timeout.
>
>
> Sylvain
>

  reply	other threads:[~2015-10-07  7:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15  7:16 at91sam9: watchdog: period Jiří Prchal
2015-05-15 13:59 ` Bryan Evenson
2015-05-15 14:19   ` Nicolas Ferre
2015-05-18  6:25     ` Jiří Prchal
2015-05-15 15:25 ` Boris Brezillon
2015-05-18  6:27   ` Jiří Prchal
2015-05-18  7:27     ` Boris Brezillon
2015-05-18  8:17       ` Jiří Prchal
2015-05-19  3:07         ` Yang, Wenyou
2015-05-19  7:14           ` Boris Brezillon
2015-05-19  9:01             ` Jiří Prchal
2015-05-19  9:14               ` Boris Brezillon
2015-05-19  9:52                 ` Jiří Prchal
2015-05-19 10:04                   ` Boris Brezillon
2015-05-20 12:39                     ` Jiří Prchal
2015-05-21 12:41                     ` Jiří Prchal
2015-05-27  7:11                       ` Jiří Prchal
2015-05-19  7:12     ` Boris Brezillon
2015-05-19  9:00       ` Jiří Prchal
2015-10-06 13:07 ` Jiří Prchal
2015-10-06 18:03 ` Sylvain Rochet
2015-10-07  7:16   ` Jiří Prchal [this message]
2015-10-07  9:22   ` Sylvain Rochet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5614C6E4.20808@aksignal.cz \
    --to=jiri.prchal@aksignal.cz \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).