[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <DB9PR10MB4652589534582A3F917E4165806D9@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
Date: Mon, 6 Dec 2021 16:37:47 +0000
From: Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To: Christoph Niedermaier <cniedermaier@...electronics.com>,
Andrej Picej <andrej.picej@...ik.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Adam Thomson <Adam.Thomson.Opensource@...semi.com>
CC: Support Opensource <Support.Opensource@...semi.com>,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
"linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Guenter Roeck <linux@...ck-us.net>
Subject: RE: [RFC PATCH] watchdog: da9062: Correct the timeout values
> Thanks anyway, so now I know it must be
> problem with my DA9061 chip.
>
> @Adam
> Where can it come from?
> Can you give we a hint what to check?
I've spoken internally and have been informed that this is down to the fact that
DA9061 runs only from an internal oscillator which may be slower. The indication
is that the values for TWDSCALE describe the window where if a kick/ping occurs
within that period then the watchdog is guaranteed *not* to timeout. The actual
timeout would be at some point after the selected timeout period, assuming no
ping/kick occurred.
Table 8 in the datasheet specifies a minimum watchdog timeout of 2.5s (tWDMAX)
under specific operating conditions, so if the minimum 2s window was chosen
(TWDSCALE = 1) then earliest the watchdog would actually timeout, following a
ping, is 2.5s, assuming the conditions matched those described.
If you have further questions it probably makes sense to contact Dialog/Renesas
support as they will be able to provide more detailed info on this.
Powered by blists - more mailing lists