Hi Morimoto-san,
On Thu, Dec 17, 2020 at 1:20 AM Kuninori Morimoto
<kuninori.morimoto.gx@xxxxxxxxxxx> wrote:
> > > Reported-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> >
> > Feel free to use geert+renesas@xxxxxxxxx instead ;-)
>
> OK, will do
>
> > The patch looks good to me, but I also cannot trigger the issue at will.
> > I went through my old boot logs, and found 2 other occurrences, also
> > on Ebisu. In all cases, it happened while a lot of output was printed to
> > the serial console (either a WARN() splat, or DEBUG_PINCTRL output).
> > My guess is that console output or disabling interrupts too long is
> > triggering a race condition or other issue in the i2c driver (clk 1 is the
> > cs2000 clock generator, controlled through i2c).
>
> OK, Thanks, nice to know.
> It was rare case issue, difficult to find :)
>
> > > } else {
> > > - clk_disable_unprepare(clk);
> > > + if (adg->clk_rate[i])
> > > + clk_disable_unprepare(clk);
> >
> > As pointed out by Mark, you may want to clear adg->clk_rate[i] here?
>
> I thought we can re-get clock if we could get clock once.
Indeed. If a clock worked before, it should keep on working.
However, the failing clock was the cs2000 clock, which can fail to enable
if something goes wrong with i2c.
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
