Hi Tony,

On Thu, Mar 31, 2022 at 12:42:10PM +0300, Tony Lindgren wrote:
> * Maxime Ripard <maxime@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@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@0 {
> 	assigned-clocks = <&gpt1_fck>;
> 	assigned-clock-parents = <&omap_32k_fck>;
> };

I haven't been able to find an omap3 board or a qemu target that could
help me debug this, but I fixed a few issues already that could fix omap
as well.

Could you test today's
https://github.com/mripard/linux/tree/rpi/clk-improvements-more-fixes

And let me know if it works?

Thanks!
Maxime