[PATCH v8 0/6] OMAP: WDT: Implement WDT in hwmod way

[Varadarajan, Charulatha]

Kevin,

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at deeprootsystems.com]

<<snip>>

> >>
> >> I found a little snag with this series.  Try testing with
> >> omap2plus_defconfig and changing CONFIG_OMAP_WATCHDOG=n.
> >>
> >> If CONFIG_OMAP_WATCHDOG is not enabled in the kernel config, the system
> >> will reboot soon after bootup.
> >
> > Thanks for finding this issue.
> >
> > After watchdog module reset, the WDTs are enabled. The default time
> > for a system reset after a watchdog module reset is ~10s as per the
> > default value of the WDT registers. Hence the above problem is observed.
> >
> > If CONFIG_OMAP_WATCHDOG is defined, wdt's probe is called within this
> > 10s time and watchdog_disable is called during probe. Hence we are not
> > finding this issue if CONFIG_OMAP_WATCHDOG is defined.
> >
> > Ideally, because of the above, watchdog should be with
> > HWMOD_INIT_NO_RESET flag.
> >
> > If agreed, I would send the below patch (extended to other OMAPs)
> > on top of my watchdog timer hwmod series with proper change log.
> 
> Using HWMOD_INIT_NO_RESET makes us still dependent on the bootloader
> settings.

Agreed.

> 
> Instead, I would rather have a small piece of code in omap_init_wdt()
> which disarms the watchdog so we don't have any assumptions about
> bootloader behavior.
> 
> The question remains whether this disarm should be
> #ifndef CONFIG_OMAP_WATCHDOG or if it should happen all the time.  In
> case the watchdog is a module, it's probe may not happen within the
> timeout period and they system may reboot also, so I lean towards
> disarming the watchdog unconditionally.

Agreed. But this shall be handled in mach-omap2/devices.c by directly
accessing the watchdog registers and disabling it, as the watchdog driver
would not be available by this time. If this okay, I would send a
separate patch on top my hwmod series to handle this.

-V Charulatha

<<snip>>