Thread (10 messages) 10 messages, 5 authors, 2012-07-16

Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option

flat view

From: Josh Boyer <hidden>
Date: 2012-07-16 20:57:34

On Mon, Jul 16, 2012 at 4:28 PM, Tabi Timur-B04825 [off-list ref] wrote:
On Fri, Jul 13, 2012 at 7:25 AM, Josh Boyer [off-list ref] wrote:
quoted
Right now, if the option is not set we call booke_wdt_disable which
indeed does not actually _disable_ the WDT, but it does set the timer
period to the maxium value.  We could go one step further and implement
a simple timer that pops and calls booke_wdt_ping if WATCHDOG_NOWAYOUT
is not set, then rearms itself.  That would leave the user with the
ability to perform recovery of the userspace process that exited or
died and was responsible for pinging the watchdog.
I think the maximum value is still decades or centuries, so there's no
real reason to complicate the code.
I have no idea about FSL cores, but the 4xx maximum value selects TBU
bit 31.  When that bit flips is going to be determined by the speed of
the clock driving TB.  Most of the 4xx implementations I have seen use
the CPU clock, so to take the example from the 44x user manuals, a 400
MHz clock results in a maximum time period of ~21 seconds.  Multiply
by 3 to get the time before the WDT actually does a reset and you're
at about 1min.
The NOWAYOUT feature is working as designed, so I don't understand the
need for this patch.
NOWAYOUT is working.  The patch was basically forcing it on, even if
the end user doesn't want the behavior described.  From what you've
said, that simply doesn't matter in the FSL case because the machine
will run for a really long time.  On 4xx, something needs to be done
to keep the machine running if the user doesn't want the NOWAYOUT
behavior, which is why I suggested a kernel timer.

josh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help