[PATCH] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init

Varadarajan, Charulatha charu at ti.com
Thu Sep 30 11:55:26 EDT 2010


Tony/ Benoit,

> >
> > I think that disabling it should be done only if the CONFIG_OMAP_WDT
> > is not set.
> 
> How about disabling is done always unless CONFIG_WATCHDOG_NOWAYOUT
> is set? 

As given in the patch description, this patch does a disable of watchdog
timer, during init, to avoid the system rebooting that happens due to
enabling of watchdog timer after a reset of the module (during hwmod init).

According to the default WDT registers values, the system reboot would
happen in ~10s if watchdog is enabled with default values. Hence, after
a WDT module reset during init, the watchdog has to be disabled within 10s
otherwise the system will keep rebooting.

Hence irrespective of CONFIG_WATCHDOG_NOWAYOUT/ CONFIG_OMAP_WDT,
the watchdog timer needs to be disabled after a WDT reset has happened.

Later on, the watchdog timer probe would be called (if CONFIG_OMAP_WDT
is defined) which takes care of doing the regular the watchdog timer
settings. After this, normal operations like open, close, ioctl operations
are supported (if CONFIG_OMAP_WDT is defined).
Based on CONFIG_WATCHDOG_NOWAYOUT definition, disabling the watchdog
may/may not be supported. 

Hence omap2_disable_wdt() introduced in this patch is not going to affect
the watchdog operations in anyway execpt that it is fixing the reboot issue
observed due to a watchdog timer reset. And this has to be done irrespective
of any OMAP watchdog timer related flags.

I guess, omap_wdt_disable() call during the WDT probe might be due to
similar reasons.

> That way product kernels can set CONFIG_WATCHDOG_NOWAYOUT
> and for the rest of us we can let fsck run the standard Linux way.
> 
> Tony


More information about the linux-arm-kernel mailing list