On 22/11/15 02:32, Guenter Roeck wrote: > On 11/21/2015 01:44 PM, Simon Arlott wrote: >> On 21/11/15 21:32, Guenter Roeck wrote: >>> this is really doing a bit too much in a single patch. >>> Conversion to the watchdog infrastructure should probably be >>> the first step, followed by further optimizations and improvements. >> I've split patch 4 up into 7 patches, which will be patches 4/10..10/10 in this thread. Instead of using bcm63xx_timer_register in #ifdefs, I'll remove most of bcm63xx_timer because it's only used by the watchdog. >>> We have some infrastructure changes in the works which will move >>> the need for soft-timers from individual drivers into the watchdog core. >>> Would this possibly be helpful here ? The timer-driven watchdog ping >>> seems to accomplish pretty much the same. >> >> There is no need for a software timer. This is not a timer-driven >> watchdog ping, there is an unmaskable timer interrupt when the watchdog >> timer has less than 50% remaining. >> > Ok. Maybe I got confused by the interrupt-triggered watchdog ping. > I'll have to look into that much more closely; it is quite unusual > and complex. The explanation is also not easy to understand. > What does "The only way to stop this interrupt" mean ? Repeatedly The interrupt is level triggered at less than 50% of the time remaining. Unless the watchdog is stopped or restarted, the interrupt will not stop occurring. > triggering the interrupt in 1/2, 1/4, 1/8 of the remaining time is > really odd. It's a bit odd but there's no way to ack the interrupt. This seemed like the best approach without adding the complexity of a software timer or trying to mask and unmask the timer interrupt. I don't want to ignore the interrupt entirely because I'd like to know if the watchdog is going to cause a reboot. > On side note, the subject tag should be "watchdog:", not "MIPS:". Fixed. -- Simon Arlott
