Hi Biju,
On Mon, Nov 14, 2022 at 7:42 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > -----Original Message-----
> > From: Prabhakar <prabhakar.csengg@xxxxxxxxx>
> > Sent: 14 November 2022 18:09
> > To: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>; Wim Van Sebroeck
> > <wim@xxxxxxxxxxxxxxxxxx>; Guenter Roeck <linux@xxxxxxxxxxxx>; Philipp Zabel
> > <p.zabel@xxxxxxxxxxxxxx>; linux-watchdog@xxxxxxxxxxxxxxx
> > Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-renesas-soc@xxxxxxxxxxxxxxx;
> > Prabhakar <prabhakar.csengg@xxxxxxxxx>; Biju Das
> > <biju.das.jz@xxxxxxxxxxxxxx>; Fabrizio Castro
> > <fabrizio.castro.jz@xxxxxxxxxxx>; Prabhakar Mahadev Lad <prabhakar.mahadev-
> > lad.rj@xxxxxxxxxxxxxx>
> > Subject: [PATCH] watchdog: rzg2l_wdt: Issue a reset before we put the PM
> > clocks
> >
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> >
> > On RZ/Five SoC it was observed that setting timeout (to say 1 sec) wouldn't
> > reset the system. To fix this we make sure we issue a reset before putting
> > the PM clocks to make sure the registers have been cleared.
> >
> > While at it re-used rzg2l_wdt_stop() in rzg2l_wdt_set_timeout() as we were
> > calling the same functions here.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > ---
> > Note,
> > - This patch has been tested on RZ/G2L, RZ/V2M and RZ/Five.
> > - My initial investigation showed adding the delay after
> > pm_runtime_get_sync()
> > also fixed this issue.
> > - Do I need add the fixes tag ? what should be the operation PUT-
> > >RESET/RESET->PUT?
>
> It looks like timing issue, None of the previous devices are affected by this.
To me it looks like the device must be clocked for the reset signal
to be propagated?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
