RE: [RFC PATCH] watchdog: da9062: Correct the timeout values [Klartext]

[Christoph Niedermaier <cniedermaier@dh-electronics.com>]

From: Guenter Roeck
Sent: Monday, December 13, 2021 2:58 PM
>> From: Adam Thomson
>> Sent: Monday, December 6, 2021 5:38 PM
>>>> 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.
>>
>> So a DA9061 runs only from an internal oscillator, whereas a DA9062
>> can run on either an internal or an external oscillator. So this
>> means that the DA9061 timeout values are differ from the DA9062
>> with an external oscillator not only on my device but on all DA9061
>> devices.
>>
>> This are the values (in seconds) in comparison:
>> DA9062 (from driver): 0  2  4   8  16  32  65 131
>> DA9061 (measured):    0  3  6  12  25  51 102 204
>> =================================================
>> Difference:           0 +1 +2  +4  +9 +19 +37 +73
>>
>> In my opinion, the differences in the higher values are very huge.
>> If I expect that the watchdog triggers and I have to wait more than
>> a minute for that to happen I ask myself is there something wrong.
>>
>> @Andrej
>> I guess, you are using an external oscillator, aren't you?
>>
>> @Adam
>> Is there a way to check in the driver which oscillator is in use?
>>
>> @Maintainers
>> Is in the driver a need to distinguish between an external and an
>> internal oscillator to get the timeout values more accurate?
>>
> 
> It would be very desirable to get timeout values more accurate.
> I would not want to dictate how to implement it, though.
> It could be automatically detected if that is possible, there
> could be a devicetree clock property providing the clock
> frequency, or maybe there is some other solution.
> 
> Guenter

I am open for a good solution.
Meanwhile I measured the timeout values of my 8 available DA9061
watchdogs. I derived the following formula from the given formula
at the data sheet and the clock divider of 2^16:

f = 2^(15+TWDSCALE) / t

Formula check with the external oscillator (32kHz) TWDSCALE=7 @ 131s:
f = 2^(15+7) / 131 = 32017Hz (=> should be OK)

The timeouts of my 8 watchdogs (9061-AA) with TWDSCALE=7:
t7 = 211s => 19878Hz
t7 = 197s => 21291Hz
t7 = 203s => 20662Hz
t7 = 204s => 20560Hz
t7 = 206s => 20361Hz
t7 = 198s => 21662Hz
t7 = 200s => 20972Hz

According to the data sheet the internal oscillator should run at 25kHz.
The average frequency of my 8 devices is 20.6kHz. Maybe the data sheet
Clock value is a max value. The timeout difference on my 8 devices are
14s. So the values vary from device to device, and maybe there is also a
temperature component.

@Adam
Is there a way to check which oscillator is in use?
Is there a way to find the current oscillator frequency?
Are there any other ideas/solutions to get the timeout values more accurate?

Thanks and regards
Christoph