From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Tony Lindgren <tony@atomide.com>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mike Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
linux-clk@vger.kernel.org,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>,
linux-amlogic@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put
Date: Mon, 04 Apr 2022 12:54:02 +0200 [thread overview]
Message-ID: <12990313.uLZWGnKmhe@steina-w> (raw)
In-Reply-To: <20220404072712.bbsbkq3cpyx4xuzy@houat>
Hello Maxime,
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.
Best regards,
Alexander
[1] https://github.com/tq-steina/linux/tree/clk-fix
[2] https://github.com/tq-steina/linux/tree/clk-revert
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Tony Lindgren <tony@atomide.com>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mike Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
linux-clk@vger.kernel.org,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>,
linux-amlogic@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put
Date: Mon, 04 Apr 2022 12:54:02 +0200 [thread overview]
Message-ID: <12990313.uLZWGnKmhe@steina-w> (raw)
In-Reply-To: <20220404072712.bbsbkq3cpyx4xuzy@houat>
Hello Maxime,
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.
Best regards,
Alexander
[1] https://github.com/tq-steina/linux/tree/clk-fix
[2] https://github.com/tq-steina/linux/tree/clk-revert
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Tony Lindgren <tony@atomide.com>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mike Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
linux-clk@vger.kernel.org,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>,
linux-amlogic@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put
Date: Mon, 04 Apr 2022 12:54:02 +0200 [thread overview]
Message-ID: <12990313.uLZWGnKmhe@steina-w> (raw)
In-Reply-To: <20220404072712.bbsbkq3cpyx4xuzy@houat>
Hello Maxime,
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.
Best regards,
Alexander
[1] https://github.com/tq-steina/linux/tree/clk-fix
[2] https://github.com/tq-steina/linux/tree/clk-revert
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-04 10:54 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 16:11 [PATCH v2 0/3] clk: Some Clock Range Fixes Maxime Ripard
2022-03-25 16:11 ` [PATCH v2 1/3] clk: Initialize orphan req_rate Maxime Ripard
2022-03-29 18:36 ` Stephen Boyd
2022-03-25 16:11 ` [PATCH v2 2/3] clk: test: Test clk_set_rate_range on orphan mux Maxime Ripard
2022-03-29 18:36 ` Stephen Boyd
2022-03-25 16:11 ` [PATCH v2 3/3] clk: Drop the rate range on clk_put Maxime Ripard
2022-03-29 18:36 ` Stephen Boyd
[not found] ` <CGME20220330080612eucas1p195caaf35d900412de762a27ae02b7b9e@eucas1p1.samsung.com>
2022-03-30 8:06 ` Marek Szyprowski
2022-03-30 8:06 ` Marek Szyprowski
2022-03-30 8:47 ` Maxime Ripard
2022-03-30 8:47 ` Maxime Ripard
2022-03-31 9:42 ` Tony Lindgren
2022-03-31 9:42 ` Tony Lindgren
2022-03-31 9:42 ` Tony Lindgren
2022-03-31 9:54 ` Maxime Ripard
2022-03-31 9:54 ` Maxime Ripard
2022-03-31 9:54 ` Maxime Ripard
2022-03-31 15:00 ` Tony Lindgren
2022-03-31 15:00 ` Tony Lindgren
2022-03-31 15:00 ` Tony Lindgren
2022-03-31 15:31 ` Maxime Ripard
2022-03-31 15:31 ` Maxime Ripard
2022-03-31 15:31 ` Maxime Ripard
2022-03-31 17:00 ` Tony Lindgren
2022-03-31 17:00 ` Tony Lindgren
2022-03-31 17:00 ` Tony Lindgren
2022-03-31 21:58 ` Stephen Boyd
2022-03-31 21:58 ` Stephen Boyd
2022-03-31 21:58 ` Stephen Boyd
2022-04-01 12:28 ` Maxime Ripard
2022-04-01 12:28 ` Maxime Ripard
2022-04-01 12:28 ` Maxime Ripard
2022-04-03 2:14 ` Stephen Boyd
2022-04-03 2:14 ` Stephen Boyd
2022-04-03 2:14 ` Stephen Boyd
2022-04-01 11:55 ` (EXT) " Alexander Stein
2022-04-01 11:55 ` Alexander Stein
2022-04-01 11:55 ` Alexander Stein
2022-04-01 12:27 ` Maxime Ripard
2022-04-01 12:27 ` Maxime Ripard
2022-04-01 12:27 ` Maxime Ripard
2022-04-01 12:59 ` (EXT) " Alexander Stein
2022-04-01 12:59 ` Alexander Stein
2022-04-01 12:59 ` Alexander Stein
2022-04-01 13:04 ` Maxime Ripard
2022-04-01 13:04 ` Maxime Ripard
2022-04-01 13:04 ` Maxime Ripard
2022-04-01 13:07 ` (EXT) " Alexander Stein
2022-04-01 13:07 ` Alexander Stein
2022-04-01 13:07 ` Alexander Stein
2022-04-01 13:34 ` Maxime Ripard
2022-04-01 13:34 ` Maxime Ripard
2022-04-01 13:34 ` Maxime Ripard
2022-04-01 13:49 ` (EXT) " Alexander Stein
2022-04-01 13:49 ` Alexander Stein
2022-04-01 13:49 ` Alexander Stein
2022-04-01 14:55 ` Maxime Ripard
2022-04-01 14:55 ` Maxime Ripard
2022-04-01 14:55 ` Maxime Ripard
2022-04-04 7:06 ` (EXT) " Alexander Stein
2022-04-04 7:06 ` Alexander Stein
2022-04-04 7:06 ` Alexander Stein
2022-04-04 7:27 ` Maxime Ripard
2022-04-04 7:27 ` Maxime Ripard
2022-04-04 7:27 ` Maxime Ripard
2022-04-04 10:54 ` Alexander Stein [this message]
2022-04-04 10:54 ` (EXT) " Alexander Stein
2022-04-04 10:54 ` Alexander Stein
2022-04-07 8:09 ` Maxime Ripard
2022-04-07 8:09 ` Maxime Ripard
2022-04-07 8:09 ` Maxime Ripard
2022-04-02 17:01 ` Maxime Ripard
2022-04-02 17:01 ` Maxime Ripard
2022-04-02 17:01 ` Maxime Ripard
2022-04-07 7:53 ` Maxime Ripard
2022-04-07 7:53 ` Maxime Ripard
2022-04-07 7:53 ` Maxime Ripard
2022-04-07 8:03 ` Tony Lindgren
2022-04-07 8:03 ` Tony Lindgren
2022-04-07 8:03 ` Tony Lindgren
2022-04-07 11:08 ` Tony Lindgren
2022-04-07 11:08 ` Tony Lindgren
2022-04-07 11:08 ` Tony Lindgren
2022-04-07 13:45 ` Maxime Ripard
2022-04-07 13:45 ` Maxime Ripard
2022-04-07 13:45 ` Maxime Ripard
2022-04-08 5:03 ` Tony Lindgren
2022-04-08 5:03 ` Tony Lindgren
2022-04-08 5:03 ` Tony Lindgren
2022-03-31 9:56 ` Marek Szyprowski
2022-03-31 9:56 ` Marek Szyprowski
2022-03-31 10:19 ` Maxime Ripard
2022-03-31 10:19 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12990313.uLZWGnKmhe@steina-w \
--to=alexander.stein@ew.tq-group.com \
--cc=dmitry.osipenko@collabora.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maxime@cerno.tech \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.