Hi Morimoto-san,
On Thu, Dec 17, 2020 at 1:20 AM Kuninori Morimoto kuninori.morimoto.gx@renesas.com wrote:
Reported-by: Geert Uytterhoeven geert@linux-m68k.org
Feel free to use geert+renesas@glider.be 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