linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
Cc: Konrad Dybcio <konrad.dybcio@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Georgi Djakov <djakov@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 6/9] interconnect: qcom: rpm: Handle interface clocks
Date: Sat, 11 Mar 2023 16:35:44 +0200	[thread overview]
Message-ID: <CAA8EJpqh+A_YKbhSQB5sWj4EP9eQtNHeohDira9o-jrx3pPRNg@mail.gmail.com> (raw)
In-Reply-To: <f848061a-763e-fbf2-860c-758373e953df@linaro.org>

On Sat, 11 Mar 2023 at 16:29, Bryan O'Donoghue
<bryan.odonoghue@linaro.org> wrote:
>
> On 11/03/2023 14:01, Dmitry Baryshkov wrote:
> >>
> >> Limit the number of bus_clocks to 2 (which is the maximum that SMD
> >> RPM interconnect supports anyway) and handle non-scaling clocks
> >> separately. Update MSM8996 and SDM660 drivers to make sure they do
> >> not regress with this change.
> >>
> >> This unfortunately has to be done in one patch to prevent either
> >> compile errors or broken bisect.
> >
> > Can we determine somehow if the intf clocks are required for the whole
> > NoC or just for a single node? I don't think that clocks like a0noc_ufs
> > are requiered to be up for the whole aggre_noc. Instead they probably
> > have to be enabled only when UFS makes use of the NoC (in other words
> > when is has voted for the bandwidth).
>
> Its probably worthwhile experimenting to see if the *ufs*_clk can/should
> be added to the UFS device list of clocks.

While we were doing this for some of the clocks (PCIe and USB, if I'm
not mistaken), I think that generally this is not fully correct. In my
opinion it should be in the interconnect driver, who turns
corresponding clocks on and off. These clocks correspond to the SoC
topology, rather than the end-device.

>
> I hadn't realised we were talking about enabling the intf clocks always
> but, actually that is what we are talking about isn't it ?
>
> It seems pretty unlikely that other devices would depend on clocks named
> *ufs*
>
> OTOH "clk-aggre2-noc-clk-no-rate" may be used across different nodes,
> seems like a pretty generic name, though still suspicious it is bundled
> with UFS, likely it is only required for UFS ?!?
>
> Konrad can you try:
>
> 1. Moving the intf_clks/QoS clocks be contained to UFS alone ?
> 2. If that doesn't work just the *ufs* clocks be put there with
> 2a. "clk-aggre2-noc-clk-no-rate" alone added to the intf_clk list
>
> It seems wrong to be enabling ufs related NoC clocks unless we are
> actually switching on UFS.

-- 
With best wishes
Dmitry

  reply	other threads:[~2023-03-11 14:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 21:40 [PATCH v7 0/9] The great interconnecification fixation Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 1/9] interconnect: qcom: rpm: make QoS INVALID default Konrad Dybcio
2023-03-11 13:52   ` Dmitry Baryshkov
2023-03-08 21:40 ` [PATCH v7 2/9] interconnect: qcom: rpm: Add support for specifying channel num Konrad Dybcio
2023-03-11 13:54   ` Dmitry Baryshkov
2023-03-21 14:06   ` Georgi Djakov
2023-03-21 14:09     ` Konrad Dybcio
2023-03-21 14:21       ` Georgi Djakov
2023-03-21 14:23         ` Konrad Dybcio
2023-03-21 14:49           ` Georgi Djakov
2023-03-21 17:33             ` Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 3/9] interconnect: qcom: Sort kerneldoc entries Konrad Dybcio
2023-03-11 13:54   ` Dmitry Baryshkov
2023-03-08 21:40 ` [PATCH v7 4/9] interconnect: qcom: rpm: Rename icc desc clocks to bus_blocks Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 5/9] interconnect: qcom: rpm: Rename icc provider num_clocks to num_bus_clocks Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 6/9] interconnect: qcom: rpm: Handle interface clocks Konrad Dybcio
2023-03-10 14:21   ` Bryan O'Donoghue
2023-03-10 14:26     ` Konrad Dybcio
2023-03-10 16:47       ` Bryan O'Donoghue
2023-03-10 18:05         ` Konrad Dybcio
2023-03-11  0:16           ` Bryan O'Donoghue
2023-03-11  0:54             ` Konrad Dybcio
2023-03-11 12:11               ` Bryan O'Donoghue
2023-03-11 12:36                 ` Konrad Dybcio
2023-03-11 13:32                 ` Dmitry Baryshkov
2023-03-11 14:01   ` Dmitry Baryshkov
2023-03-11 14:29     ` Bryan O'Donoghue
2023-03-11 14:35       ` Dmitry Baryshkov [this message]
2023-03-11 14:38         ` Bryan O'Donoghue
2023-03-11 15:26           ` Dmitry Baryshkov
2023-03-21 13:58             ` Georgi Djakov
2023-03-21 14:11               ` Konrad Dybcio
2023-03-21 14:38                 ` Georgi Djakov
2023-03-21 17:38                   ` Georgi Djakov
2023-03-21 13:56   ` Georgi Djakov
2023-03-21 14:23     ` Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 7/9] interconnect: qcom: icc-rpm: Enforce 2 or 0 bus clocks Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 8/9] interconnect: qcom: rpm: Don't use clk_get_optional for bus clocks anymore Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 9/9] interconnect: qcom: msm8996: Promote to core_initcall Konrad Dybcio
2023-03-10 14:23   ` Bryan O'Donoghue
2023-03-10 14:27     ` 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=CAA8EJpqh+A_YKbhSQB5sWj4EP9eQtNHeohDira9o-jrx3pPRNg@mail.gmail.com \
    --to=dmitry.baryshkov@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=djakov@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.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 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).