| Message ID | 20200124044425.469550-2-marex@denx.de |
|---|---|
| State | Accepted |
| Commit | 11c1af60b5c779be780d105fd33232282d30b5b6 |
| Headers | show |
| Series | [1/3] watchdog: omap_wdt: Fix WDT timeout configuration | expand |
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index b9cdf70036..85425ca505 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -219,6 +219,16 @@ static int omap3_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) while ((readl(&priv->regs->wdtwwps)) & WDT_WWPS_PEND_WSPR) ; + /* Trigger the watchdog to actually reload the counter. */ + while ((readl(&priv->regs->wdtwwps)) & WDT_WWPS_PEND_WTGR) + ; + + priv->wdt_trgr_pattern = ~(priv->wdt_trgr_pattern); + writel(priv->wdt_trgr_pattern, &priv->regs->wdtwtgr); + + while ((readl(&priv->regs->wdtwwps)) & WDT_WWPS_PEND_WTGR) + ; + return 0; }
The watchdog timer value was never updated in the hardware by this driver, so the watchdog triggered on some random stale value that was left in the hardware. The TI SPRUH37C says, quote: 20.4.3.9 Modifying Timer Count/Load Values and Prescaler Setting ... After a write access, the load register value and prescaler ratio registers are updated immediately, but new values are considered only after the next consecutive counter overflow or after a new trigger command (the WDT_WTGR register). This means at least one trigger must happen. The driver probably depended on someone calling it's .reset() callback, however that is not guaranteed e.g. if the WDT operates without servicing. Add this missing trigger. Signed-off-by: Marek Vasut <marex at denx.de> Cc: Grygorii Strashko <grygorii.strashko at ti.com> Cc: Sam Protsenko <semen.protsenko at linaro.org> Cc: Suniel Mahesh <sunil.m at techveda.org> --- drivers/watchdog/omap_wdt.c | 10 ++++++++++ 1 file changed, 10 insertions(+)