Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <c96bffda-73bc-0cdf-c77a-39d57abe1a95@ti.com>
Date:   Mon, 21 Feb 2022 10:29:20 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCHv4 3/4] watchdog: rti-wdt: attach to running watchdog
 during probe
Content-Language: en-US
To:     Jan Kiszka <jan.kiszka@siemens.com>, Nishanth Menon <nm@ti.com>
CC:     <wim@linux-watchdog.org>, <linux@roeck-us.net>,
        <linux-watchdog@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20200717132958.14304-1-t-kristo@ti.com>
 <20200717132958.14304-4-t-kristo@ti.com>
 <a80b83c6-cca5-f95c-6930-a6f3e79c6f15@siemens.com>
 <bdecc38d-2b1a-9605-0978-5ad1e8b39e6b@siemens.com>
 <20220221124405.o7vda3zaswi6ycrh@favored>
 <8a3f83be-172b-a0c8-d4ba-befa531e52f6@siemens.com>
 <dae15cec-5d05-a48d-8c3b-392559d8bfb7@siemens.com>
From:   Hari Nagalla <hnagalla@ti.com>
In-Reply-To: <dae15cec-5d05-a48d-8c3b-392559d8bfb7@siemens.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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