diff mbox series

[v1,3/3] arm64: dts: qcom: ipq5332: Add icc provider ability to gcc

Message ID 20240709063949.4127310-4-quic_varada@quicinc.com (mailing list archive)
State Handled Elsewhere, archived
Headers show
Series Add interconnect driver for IPQ5332 SoC | expand

Commit Message

Varadarajan Narayanan July 9, 2024, 6:39 a.m. UTC
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.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
 arch/arm64/boot/dts/qcom/ipq5332.dtsi | 2 ++
 1 file changed, 2 insertions(+)

Comments

Konrad Dybcio July 9, 2024, 9:53 a.m. UTC | #1
On 9.07.2024 8:39 AM, 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.
> 
> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> ---

Doesn't the USB host need to have its path described to keep working?

Konrad
Varadarajan Narayanan July 10, 2024, 10:42 a.m. UTC | #2
On Tue, Jul 09, 2024 at 11:53:41AM +0200, Konrad Dybcio wrote:
> On 9.07.2024 8:39 AM, 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.
> >
> > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> > ---
>
> Doesn't the USB host need to have its path described to keep working?

Presently, USB host enables GCC_SNOC_USB_CLK directly using
the clocks/clock-name entries. So it is not dependent on ICC.

Shall I update the USB DT node to use interconnects now itself,
or wait until this IPQ5332 ICC enablement series is approved?
Please let me know.

Thanks
Varada
Konrad Dybcio July 10, 2024, 10:49 a.m. UTC | #3
On 10.07.2024 12:42 PM, Varadarajan Narayanan wrote:
> On Tue, Jul 09, 2024 at 11:53:41AM +0200, Konrad Dybcio wrote:
>> On 9.07.2024 8:39 AM, 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.
>>>
>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>> ---
>>
>> Doesn't the USB host need to have its path described to keep working?
> 
> Presently, USB host enables GCC_SNOC_USB_CLK directly using
> the clocks/clock-name entries. So it is not dependent on ICC.
> 
> Shall I update the USB DT node to use interconnects now itself,
> or wait until this IPQ5332 ICC enablement series is approved?
> Please let me know.

Definitely so. Now that you registered that clock with the
interconnect framework, the current usage is essentially
circumventing it..

Say some consumers casted an ICC vote on that node, and then
the USB driver called set_rate on the clock.. The data from
icc-clk would be discarded

Konrad
Varadarajan Narayanan July 10, 2024, 11:12 a.m. UTC | #4
On Wed, Jul 10, 2024 at 12:49:13PM +0200, Konrad Dybcio wrote:
> On 10.07.2024 12:42 PM, Varadarajan Narayanan wrote:
> > On Tue, Jul 09, 2024 at 11:53:41AM +0200, Konrad Dybcio wrote:
> >> On 9.07.2024 8:39 AM, 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.
> >>>
> >>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> >>> ---
> >>
> >> Doesn't the USB host need to have its path described to keep working?
> >
> > Presently, USB host enables GCC_SNOC_USB_CLK directly using
> > the clocks/clock-name entries. So it is not dependent on ICC.
> >
> > Shall I update the USB DT node to use interconnects now itself,
> > or wait until this IPQ5332 ICC enablement series is approved?
> > Please let me know.
>
> Definitely so. Now that you registered that clock with the
> interconnect framework, the current usage is essentially
> circumventing it..
>
> Say some consumers casted an ICC vote on that node, and then
> the USB driver called set_rate on the clock.. The data from
> icc-clk would be discarded

Will update, test and post a new version.

Thanks
Varada
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
index 573656587c0d..7a39e66d51f1 100644
--- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
@@ -8,6 +8,7 @@ 
 #include <dt-bindings/clock/qcom,apss-ipq.h>
 #include <dt-bindings/clock/qcom,ipq5332-gcc.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interconnect/qcom,ipq5332.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -208,6 +209,7 @@  gcc: clock-controller@1800000 {
 			reg = <0x01800000 0x80000>;
 			#clock-cells = <1>;
 			#reset-cells = <1>;
+			#interconnect-cells = <1>;
 			clocks = <&xo_board>,
 				 <&sleep_clk>,
 				 <0>,