On 12/14/23 16:09, Sam Protsenko wrote: > On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: >> >> >> >> On 12/14/23 15:37, Sam Protsenko wrote: >>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: >>>> >>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock >>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement, >>>> which then makes the system hang. To prevent this, mark >>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked >>>> accordingly when tested. >>>> >>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> >>>> --- >>>> drivers/clk/samsung/clk-gs101.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c >>>> index 3d194520b05e..08d80fca9cd6 100644 >>>> --- a/drivers/clk/samsung/clk-gs101.c >>>> +++ b/drivers/clk/samsung/clk-gs101.c >>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = { >>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS, >>>> 21, 0, 0), >>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip", >>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0), >>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0), >>> >>> This clock doesn't seem like a leaf clock. It's also not a bus clock. >>> Leaving it always running makes the whole PERIC0 CMU clocked, which >>> usually should be avoided. Is it possible that the system freezes >>> because some other clock (which depends on peric0_ip) gets disabled as >>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which >>> is not implemented yet in the clock driver? Just looks weird to me >>> that the system hangs because of CMU IP clock disablement. It's >>> usually something much more specific. >> >> The system hang happened when I tested USI8 in I2C configuration with an >> eeprom. After the eeprom is read the leaf gate clock that gets disabled >> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume >> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP) >> disablement which makes the system hang. Either marking the CMU_TOP gate >> clock as critical (as I did in this patch) or marking the leaf PERIC0 >> gate clock as critical, gets rid of the system hang. Did I choose wrong? >> > > Did you already implement 100% of clocks in CMU_PERIC0? If no, there yes. > is a chance some other leaf clock (which is not implemented yet in > your driver) gets disabled as a result of PERIC0_IP disablement, which > might actually lead to that hang you observe. Usually it's some > meaningful leaf clock, e.g. GIC or interconnect clocks. Please check > clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags > and the corresponding comments I left there, maybe it'll give you more > particular idea about what to look for. Yes, making the whole CMU > always running without understanding why (i.e. because of which > particular leaf clock) might not be the best way of handling this because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK > issue. I might be mistaken, but at least please check if you > implemented all clocks for PERIC0 first and if making some meaningful > leaf clock critical makes more sense. > Thanks, ta