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

[Hari Nagalla]

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 ...