From: Maxime Ripard <maxime@cerno.tech>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mike Turquette <mturquette@baylibre.com>,
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, 1 Apr 2022 14:28:39 +0200 [thread overview]
Message-ID: <20220401122839.nn74rtftvzgjqjrg@houat> (raw)
In-Reply-To: <20220331215818.F11BEC340F0@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]
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@cerno.tech> [220331 15:29]:
> > > On Thu, Mar 31, 2022 at 06:00:42PM +0300, Tony Lindgren wrote:
> > > > * Maxime Ripard <maxime@cerno.tech> [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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mike Turquette <mturquette@baylibre.com>,
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, 1 Apr 2022 14:28:39 +0200 [thread overview]
Message-ID: <20220401122839.nn74rtftvzgjqjrg@houat> (raw)
In-Reply-To: <20220331215818.F11BEC340F0@smtp.kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1838 bytes --]
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@cerno.tech> [220331 15:29]:
> > > On Thu, Mar 31, 2022 at 06:00:42PM +0300, Tony Lindgren wrote:
> > > > * Maxime Ripard <maxime@cerno.tech> [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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
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: Maxime Ripard <maxime@cerno.tech>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mike Turquette <mturquette@baylibre.com>,
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, 1 Apr 2022 14:28:39 +0200 [thread overview]
Message-ID: <20220401122839.nn74rtftvzgjqjrg@houat> (raw)
In-Reply-To: <20220331215818.F11BEC340F0@smtp.kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1838 bytes --]
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@cerno.tech> [220331 15:29]:
> > > On Thu, Mar 31, 2022 at 06:00:42PM +0300, Tony Lindgren wrote:
> > > > * Maxime Ripard <maxime@cerno.tech> [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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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-01 12:28 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 [this message]
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
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=20220401122839.nn74rtftvzgjqjrg@houat \
--to=maxime@cerno.tech \
--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=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.