Messages in this thread | | | Date | Mon, 21 Feb 2022 10:29:20 -0600 | Subject | Re: [PATCHv4 3/4] watchdog: rti-wdt: attach to running watchdog during probe | From | 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 ... >
| |