Re: [PATCHv4 3/4] watchdog: rti-wdt: attach to running watchdog during probe

[Hari Nagalla <hnagalla@ti.com>]

On 2/21/22 10:03, Jan Kiszka wrote:
>> K, so we do want a safety margin for min_hw_heartbeat_ms, make it
>> larger. But I still don't think it is best achieved by bending the
>> frequency. That will also affect other values, e.g. returning a wrong
>> programmed timeout to userspace if that was programmed earlier, using
>> the original frequency.
>>
> I think I'm starting to get the original logic, and the result now works
> here:
> 
> The clock driving the watchdog might be slower than thought, and then we
> may time out later than intended - generally not an issue. But it may
> also be faster, and then we will see an expiry earlier than what is
> supposed to be configured via "heartbeat". For the latter case, we lower
> the frequency virtually by 10%, crossing fingers that this is enough.
> 
Humm.. To me it appears the intent is to adjust when the input 32KHz 
clock is slower? when it is slower we reduce the pulse count by 10% 
(assuming the crystals are with 10% off clock) so that the desired 
timeout is achieved with lesser pulse count?
> The problems are now:
>   - U-Boot (as a known early watchdog starter) does not do that as well,
>     and we will cause at least confusion on Linux side (60s will become
>     66s from Linux POV e.g., and we may expire at 54s already)
>      => U-Boot should add the same 10%, patch will be sent
Yes, i see that we need similar adjustment in u-boot as well.
>   - even with U-Boot on the same page, the rounding issue will prevent
>     accurate calculations of derived values, namely min_hw_heartbeat_ms.
>      => patch to come
>   - and ...
>