On 12.06.24 13:28, Varadarajan Narayanan wrote:
On Wed, Jun 12, 2024 at 11:48:17AM +0300, Georgi Djakov wrote:
On 12.06.24 9:30, Varadarajan Narayanan wrote:
On Tue, Jun 11, 2024 at 02:29:48PM +0300, Georgi Djakov wrote:
On 11.06.24 12:42, Varadarajan Narayanan wrote:
On Thu, Jun 06, 2024 at 04:06:01PM +0200, Konrad Dybcio wrote:
On 8.05.2024 10:10 AM, Dmitry Baryshkov wrote:
On Wed, 8 May 2024 at 09:53, Varadarajan Narayanan
<quic_varada@xxxxxxxxxxx> wrote:
On Fri, May 03, 2024 at 04:51:04PM +0300, Georgi Djakov wrote:
Hi Varada,
Thank you for your work on this!
On 2.05.24 12:30, Varadarajan Narayanan wrote:
On Tue, Apr 30, 2024 at 12:05:29PM +0200, Konrad Dybcio wrote:
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@xxxxxxxxxx>
Signed-off-by: Varadarajan Narayanan <quic_varada@xxxxxxxxxxx>
---
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.
[..]
nsscc_ipq9574 was not using icc_sync_state. After adding that, I
can see the following messages printed from icc_sync_state. I
also added a print to confirm if 'p->set(n, n);' is called.
Ok, that's good! So now when all providers are using sync_state, we
can go back to the initial comment from Konrad. I think you should
re-check the tests that you did, as the current results just lead to
more questions than answers. Maybe it was just the sync-state that
was missing, or there is some other issue.
BR,
Georgi
[..]
The gcc based interconnect paths are referenced by PCIe controller
nodes. Please refer to this patch
[PATCH V5 4/6] arm64: dts: qcom: ipq9574: Add PCIe PHYs and controller nodes
https://lore.kernel.org/linux-arm-msm/20240512082858.1806694-5-quic_devipriy@xxxxxxxxxxx/
Sorry, did not post the nsscc related patches since this base ICC
patch hasn't reached closure. The nsscc patches are very similar
to this gcc based series. Wanted to gather the issues raised in
this and address them in nsscc so that it is in a more acceptable
shape.
Thanks
Varada
