Quoting Tony Lindgren (2022-03-31 10:00:09) > * Maxime Ripard <maxime@xxxxxxxxxx> [220331 15:29]: > > On Thu, Mar 31, 2022 at 06:00:42PM +0300, Tony Lindgren wrote: > > > * Maxime Ripard <maxime@xxxxxxxxxx> [220331 09:52]: > > > > On Thu, Mar 31, 2022 at 12:42:10PM +0300, Tony Lindgren wrote: > > > > > It seems the dts assigned-clock-parents no longer works now? > > > > > > > > That would make some kind of sense, __set_clk_parents calls clk_put on > > > > both the assigned clock and its parent. > > > > > > > > Could you see what parent (and why?) it tries to enforce then? > > > > > > It picks the other option available for the mux clock that only has > > > two options. No idea why, but if you have some debug patch in mind I > > > can give it a try. > > > > > > > It looks like the gpt1_fck driver might favor another parent for that > > > > rate, which, if it's an invalid configuration, shouldn't really happen? > > > > > > Hmm there's a gate clock and a mux clock, there's not really a rate > > > selection available here for the sources. > > > > If I followed the OMAP driver properly, clk_mux_determine_rate_flags is > > doing the heavy lifting, could you run your test with > > Thanks that produces some interesting output. In the working case with > the $subject patch reverted we have: I don't think clk_put() dropping a range request is very important right now. If this isn't fixed tomorrow then we should revert out this patch so systems can boot -rc1 and try to fix it in parallel.
