Hi Geert,
> Subject: Re: [PATCH v3 2/4] watchdog: rzg2l_wdt: Use force reset for WDT
> reset
>
> Hi Biju,
>
> On Mon, Jan 10, 2022 at 11:51 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> wrote:
> > > Subject: Re: [PATCH v3 2/4] watchdog: rzg2l_wdt: Use force reset for
> > > WDT reset On Tue, Jan 4, 2022 at 7:12 PM Biju Das
> > > <biju.das.jz@xxxxxxxxxxxxxx>
> > > wrote:
> > > > This patch uses the force reset(WDTRSTB) for triggering WDT reset
> > > > for restart callback. This method is faster compared to the
> > > > overflow method for triggering watchdog reset.
> > > >
> > > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
>
> > > > --- a/drivers/watchdog/rzg2l_wdt.c
> > > > +++ b/drivers/watchdog/rzg2l_wdt.c
>
> > > > #define WDT_DEFAULT_TIMEOUT 60U
> > > >
> > > > @@ -116,15 +119,11 @@ static int rzg2l_wdt_restart(struct
> > > > watchdog_device *wdev, {
> > > > struct rzg2l_wdt_priv *priv = watchdog_get_drvdata(wdev);
> > > >
> > > > - /* Reset the module before we modify any register */
> > > > - reset_control_reset(priv->rstc);
> > > > - pm_runtime_get_sync(wdev->parent);
> > >
> > > Why are these no longer needed? Because .probe() takes care of that?
> >
> > This code is added to modify WDTSET register.
> > Once watchdog is started, On the fly, we won't be able to update
> > WDTSET register. By resetting(assert/deassert) the module we can
> > update the WDTSET register. It takes 34 millisec to trigger reset.
> >
> > But with PEEN_FORCE, on the fly we can update register and it
> immediately triggers reset.
> >
> > Then why do .start() and .stop() have
> > > reset and Runtime PM handling, too?
> >
> > .start-> turns on the Clocks using Runtime PM.
> >
> > We cannot Update WDTSET/WDTEN registers, once watchdog is started.
> > Adding reset and Runtime PM handling in .stop, allows to stop the
> watchdog.
> >
> > .stop-> turns off the clock using Runtime PM and does the
> reset(assert/deassert) of the module
> > in order to modify WDTSET/WDTEN registers after stop operation.
> >
> > May be I should keep pm_runtime_get_sync(wdev->parent) in restart
> > callback, To turn on the clocks, If someone calls stop followed by
> > restart
>
> I'm still confused: .probe() turns the clock on through Runtime PM, so
> it's always running. Calling .start() merely increases the usage count,
> and a subsequent .stop() will decrease it again. But the clock keeps on
> running? What am I missing?
Sorry for the confusion. On the next patch #3, I am removing clock on through Runtime PM from probe,
In order to get balanced PM usage count with start/stop operation.
So after patch#3, .start() turns on the clock and .stop() turns off the clock.
Regards,
Biju
