Hi, On Thu, Mar 31, 2022 at 02:58:17PM -0700, Stephen Boyd wrote: > 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. Yeah, it can definitely be reverted. I'm not so sure that the issue is with this patch itself though but more that it now triggers a fault reliably. Maxime
Attachment:
signature.asc
Description: PGP signature
