[PATCH v2 3/3] clk: Drop the rate range on clk_put

[Tony Lindgren]

Hi,

* Maxime Ripard <maxime at cerno.tech> [700101 02:00]:
> Hi Marek,
> 
> On Wed, Mar 30, 2022 at 10:06:13AM +0200, Marek Szyprowski wrote:
> > On 25.03.2022 17:11, Maxime Ripard wrote:
> > > While the current code will trigger a new clk_set_rate call whenever the
> > > rate boundaries are changed through clk_set_rate_range, this doesn't
> > > occur when clk_put() is called.
> > >
> > > However, this is essentially equivalent since, after clk_put()
> > > completes, those boundaries won't be enforced anymore.
> > >
> > > Let's add a call to clk_set_rate_range in clk_put to make sure those
> > > rate boundaries are dropped and the clock drivers can react.
> > >
> > > Let's also add a few tests to make sure this case is covered.
> > >
> > > Fixes: c80ac50cbb37 ("clk: Always set the rate on clk_set_range_rate")
> > > Signed-off-by: Maxime Ripard <maxime at cerno.tech>
> > 
> > This patch landed recently in linux-next 20220328 as commit 7dabfa2bc480 
> > ("clk: Drop the rate range on clk_put()"). Sadly it breaks booting of 
> > the few of my test systems: Samsung ARM 32bit Exynos3250 based Rinato 
> > board and all Amlogic Meson G12B/SM1 based boards (Odroid C4, N2, Khadas 
> > VIM3/VIM3l). Rinato hangs always with the following oops:
> > 
> > --->8---
> > 
> > Kernel panic - not syncing: MCT hangs after writing 4 (offset:0x420)
> > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc1-00014-g7dabfa2bc480 
> > #11551
> > Hardware name: Samsung Exynos (Flattened Device Tree)
> >   unwind_backtrace from show_stack+0x10/0x14
> >   show_stack from dump_stack_lvl+0x58/0x70
> >   dump_stack_lvl from panic+0x10c/0x328
> >   panic from exynos4_mct_tick_stop+0x0/0x2c
> > ---[ end Kernel panic - not syncing: MCT hangs after writing 4 
> > (offset:0x420) ]---
> > 
> > --->8---
> > 
> > Amlogic boards hang randomly during early userspace init, usually just 
> > after loading the driver modules.
> > 
> > Reverting $subject on top of linux-next fixes all those problems.
> > 
> > I will try to analyze it a bit more and if possible provide some more 
> > useful/meaning full logs later.
> 
> I'm not sure what could go wrong there, but if you can figure out the
> clock, if it tries to set a new rate and what rate it is, it would be
> awesome :)

I'm also seeing clockevent break on omaps as a wrong source clock gets
picked.

It seems the dts assigned-clock-parents no longer works now?

So the following no longer sets omap_32k_fck as the clockevent source:

timer at 0 {
	assigned-clocks = <&gpt1_fck>;
	assigned-clock-parents = <&omap_32k_fck>;
};

Regards,

Tony