From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stephan Gerhold <stephan@gerhold.net>
Cc: Shawn Guo <shawn.guo@linaro.org>, Stephen Boyd <sboyd@kernel.org>,
Loic Poulain <loic.poulain@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] clk: qcom: smd-rpm: Report enable state to framework
Date: Wed, 10 Nov 2021 06:58:54 -0800 [thread overview]
Message-ID: <YYveLqgDUrizgC/Q@ripper> (raw)
In-Reply-To: <YYvSmEr/Fo2LPJwu@gerhold.net>
On Wed 10 Nov 06:09 PST 2021, Stephan Gerhold wrote:
> On Wed, Nov 10, 2021 at 09:15:11PM +0800, Shawn Guo wrote:
> > On Tue, Nov 09, 2021 at 11:26:21AM +0100, Stephan Gerhold wrote:
> > > On Tue, Nov 09, 2021 at 10:25:55AM +0800, Shawn Guo wrote:
> > > > Currently the enable state of smd-rpm clocks are not properly reported
> > > > back to framework due to missing .is_enabled and .is_prepared hooks.
> > > > This causes a couple of issues.
> > > >
> > > > - All those unused clocks are not voted for off, because framework has
> > > > no knowledge that they are unused. It becomes a problem for vlow
> > > > power mode support, as we do not have every single RPM clock claimed
> > > > and voted for off by client devices, and rely on clock framework to
> > > > disable those unused RPM clocks.
> > > >
> > >
> > > I posted a similar patch a bit more than a year ago [1].
> >
> > Ouch, that's unfortunate! If your patch landed, I wouldn't have had to
> > spend such a long time to figure out why my platform fails to reach vlow
> > power mode :(
> >
>
> Sorry, I was waiting for Stephen to reply and eventually decided to
> shift focus to other things first. :)
>
> The whole low-power topic is kind of frustrating on older platforms
> because they currently still lack almost everything that is necessary to
> reach those low power states. Even things that you already consider
> natural for newer platforms (such as interconnect) are still very much
> work in progress on all older ones.
>
> > > Back then one
> > > of the concerns was that we might disable critical clocks just because
> > > they have no driver using it actively. For example, not all of the
> > > platforms using clk-smd-rpm already have an interconnect driver.
> > > Disabling the interconnect related clocks will almost certainly make the
> > > device lock up completely. (I tried it back then, it definitely does...)
> > >
> > > I proposed adding CLK_IGNORE_UNUSED for the interconnect related clocks
> > > back then [2] which would allow disabling most of the clocks at least.
> > > Stephen Boyd had an alternative proposal to instead move the
> > > interconnect related clocks completely out of clk-smd-rpm [3].
> > > But I'm still unsure how this would work in a backwards compatible way. [4]
> > >
> > > Since your patches are more or less identical I'm afraid the same
> > > concerns still need to be solved somehow. :)
> >
> > I do not really understand why smd-rpm clock driver needs to be a special
> > case. This is a very common issue, mostly in device early support phase
> > where not all clock consumer drivers are ready. Flag CLK_IGNORE_UNUSED
> > and kernel cmdline 'clk_ignore_unused' are created just for that. Those
> > "broken" platforms should be booted with 'clk_ignore_unused' until they
> > have related consumer drivers in place. IMHO, properly reporting enable
> > state to framework is definitely the right thing to do, and should have
> > been done from day one.
> >
>
> ... And therefore I think we should be careful with such changes,
> especially if they would prevent devices from booting completely.
> Unfortunately the users trying to make use of old platforms are also
> often the ones who might not be aware that they suddenly need
> "clk_ignore_unused" just to boot a system that was previously working
> (mostly) fine, except for the whole low-power topic.
>
> I fully agree with you that disabling the unused clocks here is the
> right thing to do, but I think we should try to carefully flag the most
> important clocks in the driver to avoid causing too many regressions.
>
I don't fancy the idea of forcing everyone to run with specific kernel
command line parameters - in particular not as a means to avoid
"regressions".
I think the only way around this problem is to figure out how to move
the clk disablement to sync_state - probably per clock driver.
Regards,
Bjorn
next prev parent reply other threads:[~2021-11-10 14:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 2:25 [PATCH 0/3] clk: qcom: smd-rpm: Report enable state to framework Shawn Guo
2021-11-09 2:25 ` [PATCH 1/3] clk: qcom: smd-rpm: Mark clock enabled in clk_smd_rpm_handoff() Shawn Guo
2021-11-09 2:25 ` [PATCH 2/3] clk: qcom: smd-rpm: Add .is_enabled hook Shawn Guo
2021-11-09 2:25 ` [PATCH 3/3] clk: qcom: smd-rpm: Add .is_prepared hook Shawn Guo
2021-11-09 10:26 ` [PATCH 0/3] clk: qcom: smd-rpm: Report enable state to framework Stephan Gerhold
2021-11-09 15:56 ` Bjorn Andersson
2021-11-10 13:15 ` Shawn Guo
2021-11-10 13:48 ` Bjorn Andersson
2021-11-11 9:39 ` Shawn Guo
2021-12-06 15:42 ` Bjorn Andersson
2021-11-10 14:09 ` Stephan Gerhold
2021-11-10 14:58 ` Bjorn Andersson [this message]
2021-12-09 9:10 ` Stephen Boyd
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=YYveLqgDUrizgC/Q@ripper \
--to=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=sboyd@kernel.org \
--cc=shawn.guo@linaro.org \
--cc=stephan@gerhold.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).