public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan@gerhold.net>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: Stephan Gerhold <stephan.gerhold@kernkonzept.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Andy Gross <agross@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] clk: qcom: smd: Disable unused clocks
Date: Mon, 9 Oct 2023 22:15:47 +0200	[thread overview]
Message-ID: <ZSRfc_w19h-55Bib@gerhold.net> (raw)
In-Reply-To: <bc8fa799-aa64-4b69-97ce-8f1872c8eb11@linaro.org>

On Fri, Oct 06, 2023 at 11:08:39PM +0200, Konrad Dybcio wrote:
> On 4.10.2023 14:10, Stephan Gerhold wrote:
> > At the moment, clk-smd-rpm forces all clocks on at probe time (for
> > "handoff"). However, it does not make the clk core aware of that.
> > 
> > This means that the clocks stay enabled forever if they are not used
> > by anything. We can easily disable them again after bootup has been
> > completed, by making the clk core aware of the state. This is
> > implemented by returning the current state of the clock in
> > is_prepared().
> > 
> > Checking the SPMI clock registers reveals that this allows the RPM to
> > disable unused BB/RF clocks. This reduces the power consumption quite
> > significantly and is also needed to allow entering low-power states.
> > 
> > As of commit d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out
> > interconnect bus clocks") the interconnect-related clocks are no longer
> > managed/exposed by clk-smd-rpm. Also the BI_TCXO_AO clock is now
> > critical (and never disabled).
> > 
> > There is still a slight chance that this change will break boot on some
> > devices. However, this will be most likely caused by actual mistakes in
> > the device tree (where required clocks were not actually specified).
> Precisely this, and solely as a consequence of the interconnect driver
> not covering all the required clocks (usually named GCC_SOME_NOC_XYZ_CLK,
> but there's quite a lot more).
> 
> For platforms without an interconnect driver, breaking stuff this **MOST
> LIKELY** means that Linux uses some hw that isn't voted for (e.g. missing
> crypto clock under scm or something).
> 
> For those with an interconnect driver, this will uncover issues that were
> previously hidden because of the smd-rpm interconnect being essentially
> broken for most of its existence. I can smell 660 breaking from however
> many miles you are away from me, but it's "good", as we were relying on
> (board specific) magic..
> 
> I've been carrying an equivalent patch in my tree for over half a year now
> and IIRC 8996 was mostly fine. It's also a good idea to test suspend
> (echo mem > /sys/power/state) and wakeup.
> 

I didn't notice any problems on 8916 and 8909 either. :-)

> For reasons that I don't fully recall, I do have both .is_prepared and
> .is_enabled though..
> 

clk-smd-rpm doesn't have any .enable()/.disable() ops (only .prepare()
and .unprepare()) so I don't think is_enabled is needed. For the unused
clock cleanup in drivers/clk/clk.c (clk_disable_unused()) we just care
about the clk_unprepare_unused_subtree() part. That part is run when the
clock reports true in .is_prepared(). The equivalent for .is_enabled()
would just be a no-op because there are no .enable()/.disable() ops.

Thanks,
Stephan

  reply	other threads:[~2023-10-09 20:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04 12:10 [PATCH v2] clk: qcom: smd: Disable unused clocks Stephan Gerhold
2023-10-06 21:08 ` Konrad Dybcio
2023-10-09 20:15   ` Stephan Gerhold [this message]
2023-10-10 20:45     ` Konrad Dybcio
2023-10-10 21:21       ` Stephan Gerhold
2023-10-10 21:22         ` Konrad Dybcio

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=ZSRfc_w19h-55Bib@gerhold.net \
    --to=stephan@gerhold.net \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=stephan.gerhold@kernkonzept.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox