I'm trying to implement support for a board specific watchdog on a PPC440EPx 
board with a very short timeout. In this case, the watchdog has to 
be "kicked" at least every 100ms, even while booting and the real watchdog 
driver not running yet. While looking for trigger places in the kernel 
source, I noticed the already existing "touch_nmi_watchdog()" function, which 
seems to be doing what I need. Even if the name not exactly matches my 
hardware setup.

My question now is, is it recommended to use this 
touch_nmi_watchdog() "infrastructure" for my PPC custom specific watchdog 
during bootup? And if yes, should it perhaps be renamed to a more generic 
name, like "touch_watchdog"?

Please advise. Thanks.

Best regards,
Stefan
-

[ message continues ]

No idea really.  Who would design a watchdog with such a short trigger
time?  That doesn't seem to be useful in any way.

--
Len Sorensen
-

[ message continues ]

On Mon, 29 Oct 2007 15:45:03 -0400

To some degree, it's configurable.  But the generic question still
stands.  It seems like a decent idea to me.  Making touch_watchdog (or
whatever it winds up being called) nice across arches might be fun.

josh
-

[ message continues ]

[added linuxppc-dev since it's PPC relevant too]


It definitely is useful in our case, since its a requirement for 
this "critical" project. It's not needed to have such a short trigger time 
while booting, but unfortunately this external watchdog only supports one 


I already have it running on my system using a quick hack (see patch below) in 
include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean 
implementation, that has chances for upstream merge (in arch/powerpc later), 
I would really like to hear if I should move on further this way. 

My impression is, that changing the name from touch_nmi_watchdog() to 
something like touch_watchdog(), and therefore touching lots of files, makes 
it more unlikely that this resulting patch will get accepted. But 
implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h 
header seems also not totally correct, since it's not really an NMI in this 
case.

Any thoughts on this?

Thanks.

Best regards,
Stefan

diff --git a/include/asm-ppc/nmi.h b/include/asm-ppc/nmi.h
new file mode 100644
index 0000000..f18862b
--- /dev/null
+++ b/include/asm-ppc/nmi.h
@@ -0,0 +1,16 @@
+/*
+ *  linux/include/asm-ppc/nmi.h
+ */
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#ifdef BOARD_WATCHDOG_FUNC
+#define touch_nmi_watchdog	BOARD_WATCHDOG_FUNC
+#else
+static inline void touch_nmi_watchdog(void)
+{
+	touch_softlockup_watchdog();
+}
+#endif
+
+#endif /* ASM_NMI_H */
-

[ message continues ]

Hello Stefan,


Indeed. Using the header file <asm/nmi.h> is seriously misleading for
the PowerPC version, as is the function name touch_nmi_watchdog() -
thius has nothing to do with NMIs on PowerPC, and most probably not on
any other non-x86 architecture as well. 

To make this mechanism generally usable (which is a good idea IMO) the
names should be changed to get rid of the "nmi" reference.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It may be that your whole purpose in life is simply  to  serve  as  a
warning to others.
-

[ message continues ]

It always seemed to me that it was userspace that should poke the
watchdog as an indication user space still works on the system.  That's
how my watchdogs are managed.  I do initialize them in the boot loader
with a 3 minute timeout which is more than long enough for the system to
boot, load the driver and change the timeout to 60 seconds or whatever
I want at runtime and start the watchdog daemon.

If the kernel hangs at initializing some driver, I do NOT want the
kernel to automatically be poking the watchdog.  I want it to time out
so to me the kernel should not be able to kick the watchdog at all by
itself.

--
Len Sorensen
-

[ message continues ]