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
Could you give it a try?
Maxime
