[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9938a67b-1f6b-4955-b4c0-a9f78c55f276@linaro.org>
Date: Thu, 27 Jun 2024 00:00:35 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Varadarajan Narayanan <quic_varada@...cinc.com>,
Georgi Djakov <djakov@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, andersson@...nel.org,
mturquette@...libre.com, sboyd@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, quic_anusha@...cinc.com,
linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org
Subject: Re: [PATCH v9 6/6] arm64: dts: qcom: ipq9574: Add icc provider
ability to gcc
On 19.06.2024 9:36 AM, Varadarajan Narayanan wrote:
[...]
> Tested the patches with both gcc and nsscc providers having
> 'sync_state' set to icc_sync_state.
>
> # dmesg | grep synced
> [ 3.029820] qcom,gcc-ipq9574 1800000.clock-controller: interconnect provider is in synced state
> [ 3.470106] qcom,nsscc-ipq9574 39b00000.clock-controller: interconnect provider is in synced state
>
> I can see that icc_sync_state is getting called and clocks
> related to paths with zero bandwidth are getting disabled.
>
> Will post the NSSCC patches to get the full picture.
Going back to the original question, does removing interconnects = from
things like PCIe now make them not work / crash the device, which would
indicate the NoC clocks were indeed gated?
Konrad
Powered by blists - more mailing lists