Thread (32 messages) 32 messages, 5 authors, 2024-06-29

Re: [PATCH v9 6/6] arm64: dts: qcom: ipq9574: Add icc provider ability to gcc

From: Konrad Dybcio <hidden>
Date: 2024-06-29 13:25:55
Also in: linux-arm-msm, linux-clk, linux-pm, lkml

On 28.06.2024 10:48 AM, Varadarajan Narayanan wrote:
On Thu, Jun 27, 2024 at 12:00:35AM +0200, Konrad Dybcio wrote:
quoted
On 19.06.2024 9:36 AM, Varadarajan Narayanan wrote:

[...]

quoted
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?
Yes. With and without 'interconnects =', the following behaviour
is same
	* Boot completes
	* PCIe devices were probed succesfully and can be
	  seen in /proc/bus/pci/devices.
	* icc_sync_state is called. The system has 4 pcie nodes
	  in the DT, out of which pcie0 is not enabled.

The difference is seen in icc_sync_state

    With 'interconnects ='

	* During icc_sync_state, the following 2 clocks
	  corresponding to the interconnects of 'pcie0' get
	  disabled.

	[    2.986356] ---> clk_core_disable_lock: gcc_anoc_pcie0_1lane_m_clk
	[    3.012486] ---> clk_core_disable_lock: gcc_snoc_pcie0_1lane_s_clk

	* System shutdown also completes without issues

    Without the 'interconnects =',

	* During icc_sync_state, the following clocks
	  corresponding to the interconnects of all the 4 PCIe
	  nodes get disabled.

	[    2.887860] ---> clk_core_disable_lock: gcc_anoc_pcie0_1lane_m_clk
	[    2.913988] ---> clk_core_disable_lock: gcc_snoc_pcie0_1lane_s_clk
	[    2.939857] ---> clk_core_disable_lock: gcc_anoc_pcie1_1lane_m_clk
	[    2.965725] ---> clk_core_disable_lock: gcc_snoc_pcie1_1lane_s_clk
	[    2.991594] ---> clk_core_disable_lock: gcc_anoc_pcie2_2lane_m_clk
	[    3.017463] ---> clk_core_disable_lock: gcc_snoc_pcie2_2lane_s_clk
	[    3.043328] ---> clk_core_disable_lock: gcc_anoc_pcie3_2lane_m_clk
	[    3.069201] ---> clk_core_disable_lock: gcc_snoc_pcie3_2lane_s_clk

	* System shutdown hangs (possibly due to un-clocked
	  access of PCIe register) in pcie_pme_interrupt_enable

		[   10.773134]  dump_stack+0x18/0x24
		[   10.776779]  pcie_pme_remove+0x2c/0x88
		[   10.780078]  pcie_port_remove_service+0x50/0x74
		[   10.783725]  device_remove+0x12c/0x148
		[   10.788151]  __device_release_driver+0x65c/0x8cc
		[   10.791972]  device_release_driver+0x2c/0x44
		[   10.796746]  bus_remove_device+0xcc/0x10c
		[   10.800999]  device_del+0x14c/0x400
		[   10.804904]  device_unregister+0x18/0x34
		[   10.808203]  remove_iter+0x2c/0x3c
		[   10.812369]  device_for_each_child+0x60/0xb4
		[   10.815583]  pcie_portdrv_shutdown+0x34/0x90
		[   10.820009]  pci_device_shutdown+0x34/0x74
		[   10.824263]  device_shutdown+0x150/0x258
		[   10.828169]  kernel_restart_prepare+0x98/0xbc
		[   10.832249]  kernel_restart+0x44/0x110
		[   10.836502]  __do_sys_reboot+0x18c/0x304

I believe, this is confirms NOC clocks getting disabled by
icc_sync_state.
Yes, this looks good now, thanks.

Konrad
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help