[PATCH] powerpc, wdt: disable ratelimiting when disabling interrupts

Rasmus Villemoes rasmus.villemoes at prevas.dk
Mon Apr 12 09:04:05 CEST 2021


On 09/04/2021 16.37, Christophe Leroy wrote:
> 
> 
> Le 09/04/2021 à 16:12, Rasmus Villemoes a écrit :

>> The ratelimiting isn't really strictly needed (prior to DM WDT, no
>> such thing existed), so just disable it when we know that time no
>> longer passes and have watchdog_reset() (e.g. called from
>> decompression loop) unconditionally reset the watchdog timer.
> 
> 
> Do we need to make it that complicated ? I think before the generic
> implementation, powerpc didn't have a rate limitation at all for pinging
> the watchdog, why not go back this direction, all the time ?
> 
> I mean we could simply set reset_period to 0 at all time for powerpc (
> and change the test to time_after_eq() instead of time_after() ).

Maybe. I think I'd still prefer the one that changes the rate-limiting
to be based on get_ticks() instead of get_timer(), which did seem to
work everywhere.

IIRC, Stefan previously rejected having a config knob or board hook for
disabling the ratelimiting - changing the code [the s/after/after_eq/]
to effectively allow that by passing hw_margin_ms=0 in DT would probably
work, but seems quite hacky (especially when DT is supposed to describe
hardware).

I've also floated the option of making get_timer() return something
sensible even with interrupts off on ppc - that would also solve the
problem, and would benefit other generic code that uses get_timer()
without knowing its limitation on ppc.
https://lists.denx.de/pipermail/u-boot/2020-June/414842.html .

So, there are lots of ways of solving it. Which direction to take really
depends on which viewpoint one has:

(1) the watchdog code should, if rate-limiting at all, use an
implementation that works on all platforms [the get_ticks option]
(2) the watchdog code should, if rate-limiting at all, provide a way for
a board/platform to override or disable that
(3) get_timer() on ppc is broken, it needs to provide sensible results
at all times, even when interrupts are disabled for tens or hundreds of
milliseconds.

Rasmus


More information about the U-Boot mailing list