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

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

[Christoph Niedermaier]

Resend with [Klartext] to turn off TLS encryption.

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?


Best regards
Christoph

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

[Guenter Roeck]

On 12/13/21 1:11 AM, Christoph Niedermaier wrote:
> Resend with [Klartext] to turn off TLS encryption.
> 
> 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

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

[Christoph Niedermaier]

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

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

[Christoph Niedermaier]

From: Christoph Niedermaier
Sent: Monday, December 13, 2021 5:16 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?

As I sent my E-Mail I didn't see your answer, so here it is:

> A quick scan of the DA9062 datasheet shows that reg/field EN_32K/CRYSTAL will
> indicate the presence of a 32KHz crystal oscillator. Obviously on DA9061 that
> option isn't available.
>
> I think the problem seems to lie around determining the internal oscillator's
> frequency. Datasheet references 25Mhz in Table 9 (Watchdog Electrical
> Characteristics), but that doesn't seem to tally with your timings and I don't
> see an obvious way in the regmap to calculate this at run time. *If* the
> oscillator frequency varies from part to part, or under different environmental
> conditions, then it's going to be tough to tie this down, and you wouldn't want
> to state a timeout value that's longer than reality.

@Adam
What do you think if I add also the timeout values for the internal oscillator?
Than the values would be:

t = 2^(15+TWDSCALE) / f

Internal 25kHz oscillator: 0  2  5  10  20  41  83 167

In comparison to the
external 32kHz oscillator: 0  2  4   8  16  32  65 131

So the difference to my measured values will decrease and it will improve the
current driver towards more accurate values.

Btw if I calculate the values with 32768Hz (the typical 32kHz oscillator), I get the
following values:
32768Hz oscillator:        0  2  4   8  16  32  64 128

Regards
Christoph

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

[Christoph Niedermaier]

From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@lists.infradead.org]
Sent: Monday, December 13, 2021 11:45 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?
> 
> As I sent my E-Mail I didn't see your answer, so here it is:
> 
>> A quick scan of the DA9062 datasheet shows that reg/field EN_32K/CRYSTAL will
>> indicate the presence of a 32KHz crystal oscillator. Obviously on DA9061 that
>> option isn't available.
>>
>> I think the problem seems to lie around determining the internal oscillator's
>> frequency. Datasheet references 25Mhz in Table 9 (Watchdog Electrical
>> Characteristics), but that doesn't seem to tally with your timings and I don't
>> see an obvious way in the regmap to calculate this at run time. *If* the
>> oscillator frequency varies from part to part, or under different environmental
>> conditions, then it's going to be tough to tie this down, and you wouldn't want
>> to state a timeout value that's longer than reality.
> 
> @Adam
> What do you think if I add also the timeout values for the internal
> oscillator?
> Than the values would be:
> 
> t = 2^(15+TWDSCALE) / f
> 
> Internal 25kHz oscillator: 0  2  5  10  20  41  83 167
> 
> In comparison to the
> external 32kHz oscillator: 0  2  4   8  16  32  65 131
> 
> So the difference to my measured values will decrease and it will improve
> the
> current driver towards more accurate values.
> 
> Btw if I calculate the values with 32768Hz (the typical 32kHz oscillator), I
> get the
> following values:
> 32768Hz oscillator:        0  2  4   8  16  32  64 128

I come to the conclusion that under normal condition (room temperature) the
timeout values could be improved, but due to the used internal ring oscillator
on the DA9061 chip under extreme conditions like automotive (125 degrees) the
values come close to the DA9062 timeout values, if an external oscillator
is used. In order not to trigger too early in extreme situations, the values
must be left as they are. But I told Dialog to add a note in the data sheet
explaining the deviation when the internal oscillator is used (DA9061).

Thanks for helping me and best regards
Christoph

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

[Adam Thomson]

On 14 February 2022 18:03, Christoph Niedermaier wrote:

> I come to the conclusion that under normal condition (room temperature) the
> timeout values could be improved, but due to the used internal ring oscillator
> on the DA9061 chip under extreme conditions like automotive (125 degrees) the
> values come close to the DA9062 timeout values, if an external oscillator
> is used. In order not to trigger too early in extreme situations, the values
> must be left as they are. But I told Dialog to add a note in the data sheet
> explaining the deviation when the internal oscillator is used (DA9061).
> 
> Thanks for helping me and best regards
> Christoph

Thanks for the update. I'll also push internally for the Datasheet update
so this is clearer in the future, to avoid any misunderstandings.

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

[Andrej Picej]

On 13. 12. 21 10:11, Christoph Niedermaier wrote:
> Resend with [Klartext] to turn off TLS encryption.
> 
> 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?

You are correct, we are using external oscillator (32,768KHz).

> 
> @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?
> 
> 
> Best regards
> Christoph
> 

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

[Christoph Niedermaier]

From: Andrej Picej
Sent: Monday, December 13, 2021 3:31 PM
[...]
>> @Andrej
>> I guess, you are using an external oscillator, aren't you?
> 
> You are correct, we are using external oscillator (32,768KHz).


Thanks for the info.


Regards
Christoph

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

[Adam Thomson]

On 13 December 2021 09:11, Christoph Niedermaier wrote:

> Resend with [Klartext] to turn off TLS encryption.
>
> 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?

A quick scan of the DA9062 datasheet shows that reg/field EN_32K/CRYSTAL will
indicate the presence of a 32KHz crystal oscillator. Obviously on DA9061 that
option isn't available.

I think the problem seems to lie around determining the internal oscillator's
frequency. Datasheet references 25Mhz in Table 9 (Watchdog Electrical
Characteristics), but that doesn't seem to tally with your timings and I don't
see an obvious way in the regmap to calculate this at run time. *If* the
oscillator frequency varies from part to part, or under different environmental
conditions, then it's going to be tough to tie this down, and you wouldn't want
to state a timeout value that's longer than reality.