Hi Alexander,
On Mon, Apr 04, 2022 at 12:54:02PM +0200, Alexander Stein wrote:
> Am Montag, 4. April 2022, 09:27:12 CEST schrieb Maxime Ripard:
> > On Mon, Apr 04, 2022 at 09:06:42AM +0200, Alexander Stein wrote:
> > > Here is the requested output:
> > > ---
> > > $ ./scripts/faddr2line build_arm64/vmlinux
> > > 'clk_mux_determine_rate_flags+0x33c/0x380'
> > > clk_mux_determine_rate_flags+0x33c/0x380:
> > > clk_mux_determine_rate_flags at drivers/clk/clk.c:627
> > > ---
> > > From a first look it seems that 'best_parent' is just a NULL-pointer here.
> > > With this small fix
> > > --->8---
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index 071857ef381a..45e081330fac 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -626,7 +626,7 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,
> > >
> > > pr_crit("%s: Best parent %s (%lu)\n",
> > >
> > > __func__,
> > >
> > > - best_parent->name,
> > > + best_parent? best_parent->name : "unknown",
> > >
> > > best);
> > >
> > > return 0;
> > >
> > > --->8---
> > >
> > > The boot eventually get stuck, but at a later point.Which is probably why
> > > your analysis found nothing strange. Due to the size of the output I put
> > > it on a gist on github [1]. Please note that this is still based on a
> > > next-20220331 based tree without the revert.
> >
> > I've looked into it over the weekend, and ran qemu on an imx6 to try to
> > see if it was any similar
> >
> > I believe the issue comes from the fact that the core will forward rate
> > requests structure to the parent clock as is, and if the parent clock
> > changes the parent it wants, we end up trying to use that parent in the
> > initial clock which doesn't work really well.
> >
> > I've fixed it in my branch here:
> > https://github.com/mripard/linux/commits/rpi/clk-improvements-more-fixes
>
> Thanks for providing another patchset. Unfortunately, my board hangs still at
> the same location. For reference I put a branch based on next-20220401 on [1].
> Reverting still does the jobs, a branch is shown on [2]
>
> next-20220404 has the offending patch already reverted, so this should work
> again, I did not test it on that base on purpose.
Could you give it another try with the branch I pushed today?
I've fixed some issues for exynos4 that could explain why it doesn't
boot on imx8 as well.
Maxime
Attachment:
signature.asc
Description: PGP signature
