devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Varadarajan Narayanan <quic_varada@quicinc.com>
Cc: andersson@kernel.org, mturquette@baylibre.com, sboyd@kernel.org,
	robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	djakov@kernel.org, dmitry.baryshkov@linaro.org,
	quic_anusha@quicinc.com, linux-arm-msm@vger.kernel.org,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v9 6/6] arm64: dts: qcom: ipq9574: Add icc provider ability to gcc
Date: Tue, 30 Apr 2024 12:05:29 +0200	[thread overview]
Message-ID: <27f4f3dd-9375-40cf-8c8f-1c4edf66e31b@linaro.org> (raw)
In-Reply-To: <Ziov6bWBXYXJ4Zp8@hu-varada-blr.qualcomm.com>

On 25.04.2024 12:26 PM, Varadarajan Narayanan wrote:
> On Tue, Apr 23, 2024 at 02:58:41PM +0200, Konrad Dybcio wrote:
>>
>>
>> On 4/18/24 11:23, Varadarajan Narayanan wrote:
>>> IPQ SoCs dont involve RPM in managing NoC related clocks and
>>> there is no NoC scaling. Linux itself handles these clocks.
>>> However, these should not be exposed as just clocks and align
>>> with other Qualcomm SoCs that handle these clocks from a
>>> interconnect provider.
>>>
>>> Hence include icc provider capability to the gcc node so that
>>> peripherals can use the interconnect facility to enable these
>>> clocks.
>>>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>> ---
>>
>> If this is all you do to enable interconnect (which is not the case,
>> as this patch only satisfies the bindings checker, the meaningful
>> change happens in the previous patch) and nothing explodes, this is
>> an apparent sign of your driver doing nothing.
> 
> It appears to do nothing because, we are just enabling the clock
> provider to also act as interconnect provider. Only when the
> consumers are enabled with interconnect usage, this will create
> paths and turn on the relevant NOC clocks.

No, with sync_state it actually does "something" (sets the interconnect
path bandwidths to zero). And *this* patch does nothing functionally,
it only makes the dt checker happy.

> 
> This interconnect will be used by the PCIe and NSS blocks. When
> those patches were posted earlier, they were put on hold until
> interconnect driver is available.
> 
> Once this patch gets in, PCIe for example will make use of icc.
> Please refer to https://lore.kernel.org/linux-arm-msm/20230519090219.15925-5-quic_devipriy@quicinc.com/.
> 
> The 'pcieX' nodes will include the following entries.
> 
> 	interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>,
> 			<&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>;
> 	interconnect-names = "pcie-mem", "cpu-pcie";

Okay. What about USB that's already enabled? And BIMC/MEMNOC?

> 
>> The expected reaction to "enabling interconnect" without defining the
>> required paths for your hardware would be a crash-on-sync_state, as all
>> unused (from Linux's POV) resources ought to be shut down.
>>
>> Because you lack sync_state, the interconnects silently retain the state
>> that they were left in (which is not deterministic), and that's precisely
>> what we want to avoid.
> 
> I tried to set 'sync_state' to icc_sync_state to be invoked and
> didn't see any crash.

Have you confirmed that the registers are actually written to, and with
correct values?

Konrad

  reply	other threads:[~2024-04-30 10:05 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18  9:22 [PATCH v9 0/6] Add interconnect driver for IPQ9574 SoC Varadarajan Narayanan
2024-04-18  9:23 ` [PATCH v9 1/6] interconnect: icc-clk: Allow user to specify master/slave ids Varadarajan Narayanan
2024-04-22 23:00   ` Konrad Dybcio
2024-04-25 10:28     ` Varadarajan Narayanan
2024-04-25 16:21       ` Georgi Djakov
2024-04-18  9:23 ` [PATCH v9 2/6] dt-bindings: interconnect: Add Qualcomm IPQ9574 support Varadarajan Narayanan
2024-04-18 17:39   ` Krzysztof Kozlowski
2024-04-18  9:23 ` [PATCH v9 3/6] interconnect: icc-clk: Add devm_icc_clk_register Varadarajan Narayanan
2024-04-18  9:23 ` [PATCH v9 4/6] clk: qcom: common: Add interconnect clocks support Varadarajan Narayanan
2024-04-22 23:05   ` Konrad Dybcio
2024-04-25 10:30     ` Varadarajan Narayanan
2024-04-18  9:23 ` [PATCH v9 5/6] clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks Varadarajan Narayanan
2024-04-18  9:23 ` [PATCH v9 6/6] arm64: dts: qcom: ipq9574: Add icc provider ability to gcc Varadarajan Narayanan
2024-04-23 12:58   ` Konrad Dybcio
2024-04-25 10:26     ` Varadarajan Narayanan
2024-04-30 10:05       ` Konrad Dybcio [this message]
2024-05-02  9:30         ` Varadarajan Narayanan
2024-05-03 13:51           ` Georgi Djakov
2024-05-08  6:52             ` Varadarajan Narayanan
2024-05-08  8:10               ` Dmitry Baryshkov
2024-06-06 14:06                 ` Konrad Dybcio
2024-06-11  9:42                   ` Varadarajan Narayanan
2024-06-11 11:29                     ` Georgi Djakov
2024-06-12  6:30                       ` Varadarajan Narayanan
2024-06-12  8:48                         ` Georgi Djakov
2024-06-12 10:28                           ` Varadarajan Narayanan
2024-06-12 12:52                             ` Georgi Djakov
2024-06-13  3:49                               ` Varadarajan Narayanan
2024-06-19  7:36                                 ` Varadarajan Narayanan
2024-06-26 22:00                                   ` Konrad Dybcio
2024-06-28  8:48                                     ` Varadarajan Narayanan
2024-06-29 13:25                                       ` 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=27f4f3dd-9375-40cf-8c8f-1c4edf66e31b@linaro.org \
    --to=konrad.dybcio@linaro.org \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=djakov@kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=quic_anusha@quicinc.com \
    --cc=quic_varada@quicinc.com \
    --cc=robh@kernel.org \
    --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 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).