From: Tony Lindgren <tony@atomide.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: 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,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put
Date: Fri, 8 Apr 2022 08:03:45 +0300 [thread overview]
Message-ID: <Yk/CMUZ6zRSzYruS@atomide.com> (raw)
In-Reply-To: <20220407134514.sct7g23yto47ylgr@houat>
* Maxime Ripard <maxime@cerno.tech> [220407 13:43]:
> On Thu, Apr 07, 2022 at 02:08:05PM +0300, Tony Lindgren wrote:
> > It now boots, but does a lot of checks on the clocks before the timers
> > get initialized compared to v5.18-rc1.
>
> I was about to say that this is fairly normal with the new behaviour,
> but I've reworked the initial patch in that discussion to only call into
> clk_set_rate_range if there was a range on that clock to begin with.
>
> It should remove the huge majority of the checks you mentioned (and
> hopefully get rid of most of the side effects as well).
OK yeah thanks, looks good to me now. Boot time looks normal, timer clocks
are right, and runtime PM still works too.
> It shouldn't be there anymore after that rework, but I couldn't find
> wher the ssi_ssr_fck clock was defined? The only relevant driver seems
> to be omap_ssi_core.c but I don't see any clock driver registered there
> either.
I'm not seeing this warning any longer :)
FYI, this clock is defined here:
$ git grep ssi_ssr_fck_3430es2
arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi: ssi_ssr_fck: ssi_ssr_fck_3430es2 {
drivers/clk/ti/clk-3xxx.c: DT_CLK(NULL, "ssi_ssr_fck", "ssi_ssr_fck_3430es2"),
Yeah it's confusing, the clock is still created based on the node name.
I have some clean-up patches coming to fix most of the related make dtbs
checks warnings now that the clock driver changes got merged.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: 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,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put
Date: Fri, 8 Apr 2022 08:03:45 +0300 [thread overview]
Message-ID: <Yk/CMUZ6zRSzYruS@atomide.com> (raw)
In-Reply-To: <20220407134514.sct7g23yto47ylgr@houat>
* Maxime Ripard <maxime@cerno.tech> [220407 13:43]:
> On Thu, Apr 07, 2022 at 02:08:05PM +0300, Tony Lindgren wrote:
> > It now boots, but does a lot of checks on the clocks before the timers
> > get initialized compared to v5.18-rc1.
>
> I was about to say that this is fairly normal with the new behaviour,
> but I've reworked the initial patch in that discussion to only call into
> clk_set_rate_range if there was a range on that clock to begin with.
>
> It should remove the huge majority of the checks you mentioned (and
> hopefully get rid of most of the side effects as well).
OK yeah thanks, looks good to me now. Boot time looks normal, timer clocks
are right, and runtime PM still works too.
> It shouldn't be there anymore after that rework, but I couldn't find
> wher the ssi_ssr_fck clock was defined? The only relevant driver seems
> to be omap_ssi_core.c but I don't see any clock driver registered there
> either.
I'm not seeing this warning any longer :)
FYI, this clock is defined here:
$ git grep ssi_ssr_fck_3430es2
arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi: ssi_ssr_fck: ssi_ssr_fck_3430es2 {
drivers/clk/ti/clk-3xxx.c: DT_CLK(NULL, "ssi_ssr_fck", "ssi_ssr_fck_3430es2"),
Yeah it's confusing, the clock is still created based on the node name.
I have some clean-up patches coming to fix most of the related make dtbs
checks warnings now that the clock driver changes got merged.
Regards,
Tony
_______________________________________________
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: Tony Lindgren <tony@atomide.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: 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,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put
Date: Fri, 8 Apr 2022 08:03:45 +0300 [thread overview]
Message-ID: <Yk/CMUZ6zRSzYruS@atomide.com> (raw)
In-Reply-To: <20220407134514.sct7g23yto47ylgr@houat>
* Maxime Ripard <maxime@cerno.tech> [220407 13:43]:
> On Thu, Apr 07, 2022 at 02:08:05PM +0300, Tony Lindgren wrote:
> > It now boots, but does a lot of checks on the clocks before the timers
> > get initialized compared to v5.18-rc1.
>
> I was about to say that this is fairly normal with the new behaviour,
> but I've reworked the initial patch in that discussion to only call into
> clk_set_rate_range if there was a range on that clock to begin with.
>
> It should remove the huge majority of the checks you mentioned (and
> hopefully get rid of most of the side effects as well).
OK yeah thanks, looks good to me now. Boot time looks normal, timer clocks
are right, and runtime PM still works too.
> It shouldn't be there anymore after that rework, but I couldn't find
> wher the ssi_ssr_fck clock was defined? The only relevant driver seems
> to be omap_ssi_core.c but I don't see any clock driver registered there
> either.
I'm not seeing this warning any longer :)
FYI, this clock is defined here:
$ git grep ssi_ssr_fck_3430es2
arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi: ssi_ssr_fck: ssi_ssr_fck_3430es2 {
drivers/clk/ti/clk-3xxx.c: DT_CLK(NULL, "ssi_ssr_fck", "ssi_ssr_fck_3430es2"),
Yeah it's confusing, the clock is still created based on the node name.
I have some clean-up patches coming to fix most of the related make dtbs
checks warnings now that the clock driver changes got merged.
Regards,
Tony
_______________________________________________
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-08 5:03 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 ` (EXT) " Alexander Stein
2022-04-04 10:54 ` 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 [this message]
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=Yk/CMUZ6zRSzYruS@atomide.com \
--to=tony@atomide.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 \
/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.