lkml.org 
[lkml]   [2022]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCHv4 3/4] watchdog: rti-wdt: attach to running watchdog during probe
From
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 ...
>

\
 
 \ /
  Last update: 2022-02-21 19:21    [W:0.746 / U:1.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site