| Message ID | 20240403104220.1092431-2-quic_varada@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v7,1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support | expand |
On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote: > On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote: > > On 03/04/2024 12:42, Varadarajan Narayanan wrote: > > > Add interconnect-cells to clock provider so that it can be > > > used as icc provider. > > > > > > Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip > > > interfaces. This will be used by the gcc-ipq9574 driver > > > that will for providing interconnect services using the > > > icc-clk framework. > > > > > > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> > > > --- > > > v7: > > > Fix macro names to be consistent with other bindings > > > v6: > > > Removed Reviewed-by: Krzysztof Kozlowski > > > Redefine the bindings such that driver and DT can share them > > > > > > v3: > > > Squash Documentation/ and include/ changes into same patch > > > > > > qcom,ipq9574.h > > > Move 'first id' to clock driver > > > > > > --- > > > .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 + > > > .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++ > > > 2 files changed, 90 insertions(+) > > > create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h > > > > > > diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > > > index 944a0ea79cd6..824781cbdf34 100644 > > > --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > > > +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > > > @@ -33,6 +33,9 @@ properties: > > > - description: PCIE30 PHY3 pipe clock source > > > - description: USB3 PHY pipe clock source > > > > > > + '#interconnect-cells': > > > + const: 1 > > > + > > > required: > > > - compatible > > > - clocks > > > diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h > > > new file mode 100644 > > > index 000000000000..0b076b0cf880 > > > --- /dev/null > > > +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h > > > @@ -0,0 +1,87 @@ > > > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ > > > +#ifndef INTERCONNECT_QCOM_IPQ9574_H > > > +#define INTERCONNECT_QCOM_IPQ9574_H > > > + > > > +#define ICC_ANOC_PCIE0 0 > > > +#define ICC_SNOC_PCIE0 1 > > > +#define ICC_ANOC_PCIE1 2 > > > +#define ICC_SNOC_PCIE1 3 > > > +#define ICC_ANOC_PCIE2 4 > > > +#define ICC_SNOC_PCIE2 5 > > > +#define ICC_ANOC_PCIE3 6 > > > +#define ICC_SNOC_PCIE3 7 > > > +#define ICC_SNOC_USB 8 > > > +#define ICC_ANOC_USB_AXI 9 > > > +#define ICC_NSSNOC_NSSCC 10 > > > +#define ICC_NSSNOC_SNOC_0 11 > > > +#define ICC_NSSNOC_SNOC_1 12 > > > +#define ICC_NSSNOC_PCNOC_1 13 > > > +#define ICC_NSSNOC_QOSGEN_REF 14 > > > +#define ICC_NSSNOC_TIMEOUT_REF 15 > > > +#define ICC_NSSNOC_XO_DCD 16 > > > +#define ICC_NSSNOC_ATB 17 > > > +#define ICC_MEM_NOC_NSSNOC 18 > > > +#define ICC_NSSNOC_MEMNOC 19 > > > +#define ICC_NSSNOC_MEM_NOC_1 20 > > > + > > > +#define ICC_NSSNOC_PPE 0 > > > +#define ICC_NSSNOC_PPE_CFG 1 > > > +#define ICC_NSSNOC_NSS_CSR 2 > > > +#define ICC_NSSNOC_IMEM_QSB 3 > > > +#define ICC_NSSNOC_IMEM_AHB 4 > > > + > > > +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2) > > > +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1) > > > > Which existing Qualcomm platform has such code? > > Existing Qualcomm platforms don't use icc-clk. They use icc-rpm > or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk. > > The icc_clk_register automatically creates master & slave nodes > for each clk entry provided as input with the node-ids 'n' and > 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just > define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these > calculations. > > However, ipq9574 gives an array of clock entries as input to > icc_clk_register. To tie the order/sequence of these clock > entries correctly with the node-ids, this calculation is needed. > > > This is the third time I am asking for consistent headers. Open > > existing, recently added headers and look how it is done there. Why? > > Because I am against such calculations and see no reason for them. > > Apologies. Regret that I have to trouble you. > > In this ipq9574 case, have to reconcile between the following > feedbacks. > > 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/ > We could probably use indexed identifiers here to avoid confusion: > [ICC_BINDING_NAME] = CLK_BINDING_NAME > > 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/ > Are these supposed to be in a dt-binding header? > > 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/ > Do you use them as well in the DTS? > > Having the defines (with the calculations) seemed to to comply > with the above three feedbacks. > > Please let me know if this can be handled in a different way that > would be consistent with other Qualcomm platforms. Krzysztof, Is this ok? Can I post a new version addressing other review comments? Thanks Varada
On 09/04/2024 09:41, Varadarajan Narayanan wrote: > On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote: >> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote: >>> On 03/04/2024 12:42, Varadarajan Narayanan wrote: >>>> Add interconnect-cells to clock provider so that it can be >>>> used as icc provider. >>>> >>>> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip >>>> interfaces. This will be used by the gcc-ipq9574 driver >>>> that will for providing interconnect services using the >>>> icc-clk framework. >>>> >>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> >>>> --- >>>> v7: >>>> Fix macro names to be consistent with other bindings >>>> v6: >>>> Removed Reviewed-by: Krzysztof Kozlowski >>>> Redefine the bindings such that driver and DT can share them >>>> >>>> v3: >>>> Squash Documentation/ and include/ changes into same patch >>>> >>>> qcom,ipq9574.h >>>> Move 'first id' to clock driver >>>> >>>> --- >>>> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 + >>>> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++ >>>> 2 files changed, 90 insertions(+) >>>> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h >>>> >>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml >>>> index 944a0ea79cd6..824781cbdf34 100644 >>>> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml >>>> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml >>>> @@ -33,6 +33,9 @@ properties: >>>> - description: PCIE30 PHY3 pipe clock source >>>> - description: USB3 PHY pipe clock source >>>> >>>> + '#interconnect-cells': >>>> + const: 1 >>>> + >>>> required: >>>> - compatible >>>> - clocks >>>> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h >>>> new file mode 100644 >>>> index 000000000000..0b076b0cf880 >>>> --- /dev/null >>>> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h >>>> @@ -0,0 +1,87 @@ >>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ >>>> +#ifndef INTERCONNECT_QCOM_IPQ9574_H >>>> +#define INTERCONNECT_QCOM_IPQ9574_H >>>> + >>>> +#define ICC_ANOC_PCIE0 0 >>>> +#define ICC_SNOC_PCIE0 1 >>>> +#define ICC_ANOC_PCIE1 2 >>>> +#define ICC_SNOC_PCIE1 3 >>>> +#define ICC_ANOC_PCIE2 4 >>>> +#define ICC_SNOC_PCIE2 5 >>>> +#define ICC_ANOC_PCIE3 6 >>>> +#define ICC_SNOC_PCIE3 7 >>>> +#define ICC_SNOC_USB 8 >>>> +#define ICC_ANOC_USB_AXI 9 >>>> +#define ICC_NSSNOC_NSSCC 10 >>>> +#define ICC_NSSNOC_SNOC_0 11 >>>> +#define ICC_NSSNOC_SNOC_1 12 >>>> +#define ICC_NSSNOC_PCNOC_1 13 >>>> +#define ICC_NSSNOC_QOSGEN_REF 14 >>>> +#define ICC_NSSNOC_TIMEOUT_REF 15 >>>> +#define ICC_NSSNOC_XO_DCD 16 >>>> +#define ICC_NSSNOC_ATB 17 >>>> +#define ICC_MEM_NOC_NSSNOC 18 >>>> +#define ICC_NSSNOC_MEMNOC 19 >>>> +#define ICC_NSSNOC_MEM_NOC_1 20 >>>> + >>>> +#define ICC_NSSNOC_PPE 0 >>>> +#define ICC_NSSNOC_PPE_CFG 1 >>>> +#define ICC_NSSNOC_NSS_CSR 2 >>>> +#define ICC_NSSNOC_IMEM_QSB 3 >>>> +#define ICC_NSSNOC_IMEM_AHB 4 >>>> + >>>> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2) >>>> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1) >>> >>> Which existing Qualcomm platform has such code? >> >> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm >> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk. >> >> The icc_clk_register automatically creates master & slave nodes >> for each clk entry provided as input with the node-ids 'n' and >> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just >> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these >> calculations. >> >> However, ipq9574 gives an array of clock entries as input to >> icc_clk_register. To tie the order/sequence of these clock >> entries correctly with the node-ids, this calculation is needed. >> >>> This is the third time I am asking for consistent headers. Open >>> existing, recently added headers and look how it is done there. Why? >>> Because I am against such calculations and see no reason for them. >> >> Apologies. Regret that I have to trouble you. >> >> In this ipq9574 case, have to reconcile between the following >> feedbacks. >> >> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/ >> We could probably use indexed identifiers here to avoid confusion: >> [ICC_BINDING_NAME] = CLK_BINDING_NAME >> >> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/ >> Are these supposed to be in a dt-binding header? >> >> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/ >> Do you use them as well in the DTS? >> >> Having the defines (with the calculations) seemed to to comply >> with the above three feedbacks. >> >> Please let me know if this can be handled in a different way that >> would be consistent with other Qualcomm platforms. > > Krzysztof, > > Is this ok? Can I post a new version addressing other review comments? I don't understand and you did not answered before, why you have to do it differently than all other Qualcomm interconnect providers. Maybe the code here needs it, maybe not, but I don't see any argument proving this. Best regards, Krzysztof
On Tue, Apr 09, 2024 at 11:45:51AM +0200, Krzysztof Kozlowski wrote: > On 09/04/2024 09:41, Varadarajan Narayanan wrote: > > On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote: > >> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote: > >>> On 03/04/2024 12:42, Varadarajan Narayanan wrote: > >>>> Add interconnect-cells to clock provider so that it can be > >>>> used as icc provider. > >>>> > >>>> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip > >>>> interfaces. This will be used by the gcc-ipq9574 driver > >>>> that will for providing interconnect services using the > >>>> icc-clk framework. > >>>> > >>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> > >>>> --- > >>>> v7: > >>>> Fix macro names to be consistent with other bindings > >>>> v6: > >>>> Removed Reviewed-by: Krzysztof Kozlowski > >>>> Redefine the bindings such that driver and DT can share them > >>>> > >>>> v3: > >>>> Squash Documentation/ and include/ changes into same patch > >>>> > >>>> qcom,ipq9574.h > >>>> Move 'first id' to clock driver > >>>> > >>>> --- > >>>> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 + > >>>> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++ > >>>> 2 files changed, 90 insertions(+) > >>>> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > >>>> index 944a0ea79cd6..824781cbdf34 100644 > >>>> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > >>>> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > >>>> @@ -33,6 +33,9 @@ properties: > >>>> - description: PCIE30 PHY3 pipe clock source > >>>> - description: USB3 PHY pipe clock source > >>>> > >>>> + '#interconnect-cells': > >>>> + const: 1 > >>>> + > >>>> required: > >>>> - compatible > >>>> - clocks > >>>> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h > >>>> new file mode 100644 > >>>> index 000000000000..0b076b0cf880 > >>>> --- /dev/null > >>>> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h > >>>> @@ -0,0 +1,87 @@ > >>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ > >>>> +#ifndef INTERCONNECT_QCOM_IPQ9574_H > >>>> +#define INTERCONNECT_QCOM_IPQ9574_H > >>>> + > >>>> +#define ICC_ANOC_PCIE0 0 > >>>> +#define ICC_SNOC_PCIE0 1 > >>>> +#define ICC_ANOC_PCIE1 2 > >>>> +#define ICC_SNOC_PCIE1 3 > >>>> +#define ICC_ANOC_PCIE2 4 > >>>> +#define ICC_SNOC_PCIE2 5 > >>>> +#define ICC_ANOC_PCIE3 6 > >>>> +#define ICC_SNOC_PCIE3 7 > >>>> +#define ICC_SNOC_USB 8 > >>>> +#define ICC_ANOC_USB_AXI 9 > >>>> +#define ICC_NSSNOC_NSSCC 10 > >>>> +#define ICC_NSSNOC_SNOC_0 11 > >>>> +#define ICC_NSSNOC_SNOC_1 12 > >>>> +#define ICC_NSSNOC_PCNOC_1 13 > >>>> +#define ICC_NSSNOC_QOSGEN_REF 14 > >>>> +#define ICC_NSSNOC_TIMEOUT_REF 15 > >>>> +#define ICC_NSSNOC_XO_DCD 16 > >>>> +#define ICC_NSSNOC_ATB 17 > >>>> +#define ICC_MEM_NOC_NSSNOC 18 > >>>> +#define ICC_NSSNOC_MEMNOC 19 > >>>> +#define ICC_NSSNOC_MEM_NOC_1 20 > >>>> + > >>>> +#define ICC_NSSNOC_PPE 0 > >>>> +#define ICC_NSSNOC_PPE_CFG 1 > >>>> +#define ICC_NSSNOC_NSS_CSR 2 > >>>> +#define ICC_NSSNOC_IMEM_QSB 3 > >>>> +#define ICC_NSSNOC_IMEM_AHB 4 > >>>> + > >>>> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2) > >>>> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1) > >>> > >>> Which existing Qualcomm platform has such code? > >> > >> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm > >> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk. > >> > >> The icc_clk_register automatically creates master & slave nodes > >> for each clk entry provided as input with the node-ids 'n' and > >> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just > >> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these > >> calculations. > >> > >> However, ipq9574 gives an array of clock entries as input to > >> icc_clk_register. To tie the order/sequence of these clock > >> entries correctly with the node-ids, this calculation is needed. > >> > >>> This is the third time I am asking for consistent headers. Open > >>> existing, recently added headers and look how it is done there. Why? > >>> Because I am against such calculations and see no reason for them. > >> > >> Apologies. Regret that I have to trouble you. > >> > >> In this ipq9574 case, have to reconcile between the following > >> feedbacks. > >> > >> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/ > >> We could probably use indexed identifiers here to avoid confusion: > >> [ICC_BINDING_NAME] = CLK_BINDING_NAME > >> > >> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/ > >> Are these supposed to be in a dt-binding header? > >> > >> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/ > >> Do you use them as well in the DTS? > >> > >> Having the defines (with the calculations) seemed to to comply > >> with the above three feedbacks. > >> > >> Please let me know if this can be handled in a different way that > >> would be consistent with other Qualcomm platforms. > > > > Krzysztof, > > > > Is this ok? Can I post a new version addressing other review comments? > > I don't understand and you did not answered before, why you have to do > it differently than all other Qualcomm interconnect providers. Maybe the > code here needs it, maybe not, but I don't see any argument proving this. Other Qualcomm interconnect providers use the icc-rpm. 1. The SoC specific interconnect providers have control over the master/slave id-numbers and is hard coded. 2. These id-numbers are used by the RPM firmware. IPQ9574 uses icc-clk. 1. The ipq9574 specific interconnect provider doesn't have control over the master/slave id-numbers. The icc-clk framework auto generates it in the order of the clock entries given as input. 2. These auto-generated id-numbers have to be correctly tied to the DT nodes. Else, the relevant clocks may not get enabled. Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in the below array would create holes. static int icc_ipq9574_hws[] = { [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, . . . }; Other Qualcomm drivers don't have this issue and they can directly use the MASTER/SLAVE_xxx macros. As the MASTER_xxx macros cannot be used, have to define a new set of macros that can be used for indices in the above array. This is the reason for the ICC_BINDING_NAME macros. Does this answer your concern? Please let me know. Thanks Varada
On 09/04/2024 13:03, Varadarajan Narayanan wrote: > On Tue, Apr 09, 2024 at 11:45:51AM +0200, Krzysztof Kozlowski wrote: >> On 09/04/2024 09:41, Varadarajan Narayanan wrote: >>> On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote: >>>> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote: >>>>> On 03/04/2024 12:42, Varadarajan Narayanan wrote: >>>>>> Add interconnect-cells to clock provider so that it can be >>>>>> used as icc provider. >>>>>> >>>>>> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip >>>>>> interfaces. This will be used by the gcc-ipq9574 driver >>>>>> that will for providing interconnect services using the >>>>>> icc-clk framework. >>>>>> >>>>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> >>>>>> --- >>>>>> v7: >>>>>> Fix macro names to be consistent with other bindings >>>>>> v6: >>>>>> Removed Reviewed-by: Krzysztof Kozlowski >>>>>> Redefine the bindings such that driver and DT can share them >>>>>> >>>>>> v3: >>>>>> Squash Documentation/ and include/ changes into same patch >>>>>> >>>>>> qcom,ipq9574.h >>>>>> Move 'first id' to clock driver >>>>>> >>>>>> --- >>>>>> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 + >>>>>> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++ >>>>>> 2 files changed, 90 insertions(+) >>>>>> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml >>>>>> index 944a0ea79cd6..824781cbdf34 100644 >>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml >>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml >>>>>> @@ -33,6 +33,9 @@ properties: >>>>>> - description: PCIE30 PHY3 pipe clock source >>>>>> - description: USB3 PHY pipe clock source >>>>>> >>>>>> + '#interconnect-cells': >>>>>> + const: 1 >>>>>> + >>>>>> required: >>>>>> - compatible >>>>>> - clocks >>>>>> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h >>>>>> new file mode 100644 >>>>>> index 000000000000..0b076b0cf880 >>>>>> --- /dev/null >>>>>> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h >>>>>> @@ -0,0 +1,87 @@ >>>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ >>>>>> +#ifndef INTERCONNECT_QCOM_IPQ9574_H >>>>>> +#define INTERCONNECT_QCOM_IPQ9574_H >>>>>> + >>>>>> +#define ICC_ANOC_PCIE0 0 >>>>>> +#define ICC_SNOC_PCIE0 1 >>>>>> +#define ICC_ANOC_PCIE1 2 >>>>>> +#define ICC_SNOC_PCIE1 3 >>>>>> +#define ICC_ANOC_PCIE2 4 >>>>>> +#define ICC_SNOC_PCIE2 5 >>>>>> +#define ICC_ANOC_PCIE3 6 >>>>>> +#define ICC_SNOC_PCIE3 7 >>>>>> +#define ICC_SNOC_USB 8 >>>>>> +#define ICC_ANOC_USB_AXI 9 >>>>>> +#define ICC_NSSNOC_NSSCC 10 >>>>>> +#define ICC_NSSNOC_SNOC_0 11 >>>>>> +#define ICC_NSSNOC_SNOC_1 12 >>>>>> +#define ICC_NSSNOC_PCNOC_1 13 >>>>>> +#define ICC_NSSNOC_QOSGEN_REF 14 >>>>>> +#define ICC_NSSNOC_TIMEOUT_REF 15 >>>>>> +#define ICC_NSSNOC_XO_DCD 16 >>>>>> +#define ICC_NSSNOC_ATB 17 >>>>>> +#define ICC_MEM_NOC_NSSNOC 18 >>>>>> +#define ICC_NSSNOC_MEMNOC 19 >>>>>> +#define ICC_NSSNOC_MEM_NOC_1 20 >>>>>> + >>>>>> +#define ICC_NSSNOC_PPE 0 >>>>>> +#define ICC_NSSNOC_PPE_CFG 1 >>>>>> +#define ICC_NSSNOC_NSS_CSR 2 >>>>>> +#define ICC_NSSNOC_IMEM_QSB 3 >>>>>> +#define ICC_NSSNOC_IMEM_AHB 4 >>>>>> + >>>>>> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2) >>>>>> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1) >>>>> >>>>> Which existing Qualcomm platform has such code? >>>> >>>> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm >>>> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk. >>>> >>>> The icc_clk_register automatically creates master & slave nodes >>>> for each clk entry provided as input with the node-ids 'n' and >>>> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just >>>> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these >>>> calculations. >>>> >>>> However, ipq9574 gives an array of clock entries as input to >>>> icc_clk_register. To tie the order/sequence of these clock >>>> entries correctly with the node-ids, this calculation is needed. >>>> >>>>> This is the third time I am asking for consistent headers. Open >>>>> existing, recently added headers and look how it is done there. Why? >>>>> Because I am against such calculations and see no reason for them. >>>> >>>> Apologies. Regret that I have to trouble you. >>>> >>>> In this ipq9574 case, have to reconcile between the following >>>> feedbacks. >>>> >>>> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/ >>>> We could probably use indexed identifiers here to avoid confusion: >>>> [ICC_BINDING_NAME] = CLK_BINDING_NAME >>>> >>>> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/ >>>> Are these supposed to be in a dt-binding header? >>>> >>>> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/ >>>> Do you use them as well in the DTS? >>>> >>>> Having the defines (with the calculations) seemed to to comply >>>> with the above three feedbacks. >>>> >>>> Please let me know if this can be handled in a different way that >>>> would be consistent with other Qualcomm platforms. >>> >>> Krzysztof, >>> >>> Is this ok? Can I post a new version addressing other review comments? >> >> I don't understand and you did not answered before, why you have to do >> it differently than all other Qualcomm interconnect providers. Maybe the >> code here needs it, maybe not, but I don't see any argument proving this. > > Other Qualcomm interconnect providers use the icc-rpm. > > 1. The SoC specific interconnect providers have control > over the master/slave id-numbers and is hard coded. > > 2. These id-numbers are used by the RPM firmware. > > IPQ9574 uses icc-clk. > > 1. The ipq9574 specific interconnect provider doesn't > have control over the master/slave id-numbers. The > icc-clk framework auto generates it in the order of > the clock entries given as input. Okay, so what happens if icc-clk way of generating them changes a bit? It can change, why not, driver implementation is not an ABI. > > 2. These auto-generated id-numbers have to be correctly > tied to the DT nodes. Else, the relevant clocks may > not get enabled. Sorry, I don't get, how auto generated ID number is tied to DT node. What DT node? > > Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and > one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in > the below array would create holes. > > static int icc_ipq9574_hws[] = { > [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, > [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, > [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, > [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, > . . . > }; > > Other Qualcomm drivers don't have this issue and they can > directly use the MASTER/SLAVE_xxx macros. I understand, thanks, yet your last patch keeps adding fake IDs, means IDs which are not part of ABI. > > As the MASTER_xxx macros cannot be used, have to define a new set > of macros that can be used for indices in the above array. This > is the reason for the ICC_BINDING_NAME macros. Then maybe fix the driver, instead of adding something which is not an ABI to bindings and completely skipping the actual ABI. Best regards, Krzysztof
On Tue, Apr 09, 2024 at 02:20:12PM +0200, Krzysztof Kozlowski wrote: > On 09/04/2024 13:03, Varadarajan Narayanan wrote: > > On Tue, Apr 09, 2024 at 11:45:51AM +0200, Krzysztof Kozlowski wrote: > >> On 09/04/2024 09:41, Varadarajan Narayanan wrote: > >>> On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote: > >>>> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote: > >>>>> On 03/04/2024 12:42, Varadarajan Narayanan wrote: > >>>>>> Add interconnect-cells to clock provider so that it can be > >>>>>> used as icc provider. > >>>>>> > >>>>>> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip > >>>>>> interfaces. This will be used by the gcc-ipq9574 driver > >>>>>> that will for providing interconnect services using the > >>>>>> icc-clk framework. > >>>>>> > >>>>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> > >>>>>> --- > >>>>>> v7: > >>>>>> Fix macro names to be consistent with other bindings > >>>>>> v6: > >>>>>> Removed Reviewed-by: Krzysztof Kozlowski > >>>>>> Redefine the bindings such that driver and DT can share them > >>>>>> > >>>>>> v3: > >>>>>> Squash Documentation/ and include/ changes into same patch > >>>>>> > >>>>>> qcom,ipq9574.h > >>>>>> Move 'first id' to clock driver > >>>>>> > >>>>>> --- > >>>>>> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 + > >>>>>> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++ > >>>>>> 2 files changed, 90 insertions(+) > >>>>>> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h > >>>>>> > >>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > >>>>>> index 944a0ea79cd6..824781cbdf34 100644 > >>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > >>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml > >>>>>> @@ -33,6 +33,9 @@ properties: > >>>>>> - description: PCIE30 PHY3 pipe clock source > >>>>>> - description: USB3 PHY pipe clock source > >>>>>> > >>>>>> + '#interconnect-cells': > >>>>>> + const: 1 > >>>>>> + > >>>>>> required: > >>>>>> - compatible > >>>>>> - clocks > >>>>>> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h > >>>>>> new file mode 100644 > >>>>>> index 000000000000..0b076b0cf880 > >>>>>> --- /dev/null > >>>>>> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h > >>>>>> @@ -0,0 +1,87 @@ > >>>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ > >>>>>> +#ifndef INTERCONNECT_QCOM_IPQ9574_H > >>>>>> +#define INTERCONNECT_QCOM_IPQ9574_H > >>>>>> + > >>>>>> +#define ICC_ANOC_PCIE0 0 > >>>>>> +#define ICC_SNOC_PCIE0 1 > >>>>>> +#define ICC_ANOC_PCIE1 2 > >>>>>> +#define ICC_SNOC_PCIE1 3 > >>>>>> +#define ICC_ANOC_PCIE2 4 > >>>>>> +#define ICC_SNOC_PCIE2 5 > >>>>>> +#define ICC_ANOC_PCIE3 6 > >>>>>> +#define ICC_SNOC_PCIE3 7 > >>>>>> +#define ICC_SNOC_USB 8 > >>>>>> +#define ICC_ANOC_USB_AXI 9 > >>>>>> +#define ICC_NSSNOC_NSSCC 10 > >>>>>> +#define ICC_NSSNOC_SNOC_0 11 > >>>>>> +#define ICC_NSSNOC_SNOC_1 12 > >>>>>> +#define ICC_NSSNOC_PCNOC_1 13 > >>>>>> +#define ICC_NSSNOC_QOSGEN_REF 14 > >>>>>> +#define ICC_NSSNOC_TIMEOUT_REF 15 > >>>>>> +#define ICC_NSSNOC_XO_DCD 16 > >>>>>> +#define ICC_NSSNOC_ATB 17 > >>>>>> +#define ICC_MEM_NOC_NSSNOC 18 > >>>>>> +#define ICC_NSSNOC_MEMNOC 19 > >>>>>> +#define ICC_NSSNOC_MEM_NOC_1 20 > >>>>>> + > >>>>>> +#define ICC_NSSNOC_PPE 0 > >>>>>> +#define ICC_NSSNOC_PPE_CFG 1 > >>>>>> +#define ICC_NSSNOC_NSS_CSR 2 > >>>>>> +#define ICC_NSSNOC_IMEM_QSB 3 > >>>>>> +#define ICC_NSSNOC_IMEM_AHB 4 > >>>>>> + > >>>>>> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2) > >>>>>> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1) > >>>>> > >>>>> Which existing Qualcomm platform has such code? > >>>> > >>>> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm > >>>> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk. > >>>> > >>>> The icc_clk_register automatically creates master & slave nodes > >>>> for each clk entry provided as input with the node-ids 'n' and > >>>> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just > >>>> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these > >>>> calculations. > >>>> > >>>> However, ipq9574 gives an array of clock entries as input to > >>>> icc_clk_register. To tie the order/sequence of these clock > >>>> entries correctly with the node-ids, this calculation is needed. > >>>> > >>>>> This is the third time I am asking for consistent headers. Open > >>>>> existing, recently added headers and look how it is done there. Why? > >>>>> Because I am against such calculations and see no reason for them. > >>>> > >>>> Apologies. Regret that I have to trouble you. > >>>> > >>>> In this ipq9574 case, have to reconcile between the following > >>>> feedbacks. > >>>> > >>>> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/ > >>>> We could probably use indexed identifiers here to avoid confusion: > >>>> [ICC_BINDING_NAME] = CLK_BINDING_NAME > >>>> > >>>> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/ > >>>> Are these supposed to be in a dt-binding header? > >>>> > >>>> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/ > >>>> Do you use them as well in the DTS? > >>>> > >>>> Having the defines (with the calculations) seemed to to comply > >>>> with the above three feedbacks. > >>>> > >>>> Please let me know if this can be handled in a different way that > >>>> would be consistent with other Qualcomm platforms. > >>> > >>> Krzysztof, > >>> > >>> Is this ok? Can I post a new version addressing other review comments? > >> > >> I don't understand and you did not answered before, why you have to do > >> it differently than all other Qualcomm interconnect providers. Maybe the > >> code here needs it, maybe not, but I don't see any argument proving this. > > > > Other Qualcomm interconnect providers use the icc-rpm. > > > > 1. The SoC specific interconnect providers have control > > over the master/slave id-numbers and is hard coded. > > > > 2. These id-numbers are used by the RPM firmware. > > > > IPQ9574 uses icc-clk. > > > > 1. The ipq9574 specific interconnect provider doesn't > > have control over the master/slave id-numbers. The > > icc-clk framework auto generates it in the order of > > the clock entries given as input. > > Okay, so what happens if icc-clk way of generating them changes a bit? > It can change, why not, driver implementation is not an ABI. > > > > > 2. These auto-generated id-numbers have to be correctly > > tied to the DT nodes. Else, the relevant clocks may > > not get enabled. > > Sorry, I don't get, how auto generated ID number is tied to DT node. > What DT node? I meant the following usage for the 'interconnects' entry of the consumer peripheral's node. interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>, ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ <&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>; ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ > > Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and > > one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in > > the below array would create holes. > > > > static int icc_ipq9574_hws[] = { > > [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, > > [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, > > [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, > > [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, > > . . . > > }; > > > > Other Qualcomm drivers don't have this issue and they can > > directly use the MASTER/SLAVE_xxx macros. > > I understand, thanks, yet your last patch keeps adding fake IDs, means > IDs which are not part of ABI. > > > > > As the MASTER_xxx macros cannot be used, have to define a new set > > of macros that can be used for indices in the above array. This > > is the reason for the ICC_BINDING_NAME macros. > > Then maybe fix the driver, instead of adding something which is not an > ABI to bindings and completely skipping the actual ABI. Will remove the ICC_xxx defines from the header. And in the driver will change the declaration as follows. Will that be acceptable? static int icc_ipq9574_hws[] = { [MASTER_ANOC_PCIE0 / 2] = GCC_ANOC_PCIE0_1LANE_M_CLK, [MASTER_SNOC_PCIE0 / 2] = GCC_SNOC_PCIE0_1LANE_S_CLK, [MASTER_ANOC_PCIE1 / 2] = GCC_ANOC_PCIE1_1LANE_M_CLK, [MASTER_SNOC_PCIE1 / 2] = GCC_SNOC_PCIE1_1LANE_S_CLK, [MASTER_ANOC_PCIE2 / 2] = GCC_ANOC_PCIE2_2LANE_M_CLK, [MASTER_SNOC_PCIE2 / 2] = GCC_SNOC_PCIE2_2LANE_S_CLK, [MASTER_ANOC_PCIE3 / 2] = GCC_ANOC_PCIE3_2LANE_M_CLK, [MASTER_SNOC_PCIE3 / 2] = GCC_SNOC_PCIE3_2LANE_S_CLK, [MASTER_SNOC_USB / 2] = GCC_SNOC_USB_CLK, [MASTER_ANOC_USB_AXI / 2] = GCC_ANOC_USB_AXI_CLK, [MASTER_NSSNOC_NSSCC / 2] = GCC_NSSNOC_NSSCC_CLK, [MASTER_NSSNOC_SNOC_0 / 2] = GCC_NSSNOC_SNOC_CLK, [MASTER_NSSNOC_SNOC_1 / 2] = GCC_NSSNOC_SNOC_1_CLK, [MASTER_NSSNOC_PCNOC_1 / 2] = GCC_NSSNOC_PCNOC_1_CLK, [MASTER_NSSNOC_QOSGEN_REF / 2] = GCC_NSSNOC_QOSGEN_REF_CLK, [MASTER_NSSNOC_TIMEOUT_REF / 2] = GCC_NSSNOC_TIMEOUT_REF_CLK, [MASTER_NSSNOC_XO_DCD / 2] = GCC_NSSNOC_XO_DCD_CLK, [MASTER_NSSNOC_ATB / 2] = GCC_NSSNOC_ATB_CLK, [MASTER_MEM_NOC_NSSNOC / 2] = GCC_MEM_NOC_NSSNOC_CLK, [MASTER_NSSNOC_MEMNOC / 2] = GCC_NSSNOC_MEMNOC_CLK, [MASTER_NSSNOC_MEM_NOC_1 / 2] = GCC_NSSNOC_MEM_NOC_1_CLK, }; Thanks Varada
On 10/04/2024 12:02, Varadarajan Narayanan wrote: >> Okay, so what happens if icc-clk way of generating them changes a bit? >> It can change, why not, driver implementation is not an ABI. >> >>> >>> 2. These auto-generated id-numbers have to be correctly >>> tied to the DT nodes. Else, the relevant clocks may >>> not get enabled. >> >> Sorry, I don't get, how auto generated ID number is tied to DT node. >> What DT node? > > I meant the following usage for the 'interconnects' entry of the > consumer peripheral's node. > > interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>, > ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ > <&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>; > ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ > >>> Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and >>> one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in >>> the below array would create holes. >>> >>> static int icc_ipq9574_hws[] = { >>> [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, >>> [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, >>> [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, >>> [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, >>> . . . >>> }; >>> >>> Other Qualcomm drivers don't have this issue and they can >>> directly use the MASTER/SLAVE_xxx macros. >> >> I understand, thanks, yet your last patch keeps adding fake IDs, means >> IDs which are not part of ABI. >> >>> >>> As the MASTER_xxx macros cannot be used, have to define a new set >>> of macros that can be used for indices in the above array. This >>> is the reason for the ICC_BINDING_NAME macros. >> >> Then maybe fix the driver, instead of adding something which is not an >> ABI to bindings and completely skipping the actual ABI. > > Will remove the ICC_xxx defines from the header. And in the > driver will change the declaration as follows. Will that be > acceptable? > > static int icc_ipq9574_hws[] = { > [MASTER_ANOC_PCIE0 / 2] = GCC_ANOC_PCIE0_1LANE_M_CLK, What is the binding in such case? What exactly do you bind between driver and DTS? Best regards, Krzysztof
On 4/10/24 13:15, Krzysztof Kozlowski wrote: > On 10/04/2024 12:02, Varadarajan Narayanan wrote: >>> Okay, so what happens if icc-clk way of generating them changes a bit? >>> It can change, why not, driver implementation is not an ABI. >>> >>>> >>>> 2. These auto-generated id-numbers have to be correctly >>>> tied to the DT nodes. Else, the relevant clocks may >>>> not get enabled. >>> >>> Sorry, I don't get, how auto generated ID number is tied to DT node. >>> What DT node? >> >> I meant the following usage for the 'interconnects' entry of the >> consumer peripheral's node. >> >> interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>, >> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ >> <&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>; >> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ >> >>>> Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and >>>> one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in >>>> the below array would create holes. >>>> >>>> static int icc_ipq9574_hws[] = { >>>> [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, >>>> [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, >>>> [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, >>>> [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, >>>> . . . >>>> }; >>>> >>>> Other Qualcomm drivers don't have this issue and they can >>>> directly use the MASTER/SLAVE_xxx macros. >>> >>> I understand, thanks, yet your last patch keeps adding fake IDs, means >>> IDs which are not part of ABI. >>> >>>> >>>> As the MASTER_xxx macros cannot be used, have to define a new set >>>> of macros that can be used for indices in the above array. This >>>> is the reason for the ICC_BINDING_NAME macros. >>> >>> Then maybe fix the driver, instead of adding something which is not an >>> ABI to bindings and completely skipping the actual ABI. >> >> Will remove the ICC_xxx defines from the header. And in the >> driver will change the declaration as follows. Will that be >> acceptable? >> >> static int icc_ipq9574_hws[] = { >> [MASTER_ANOC_PCIE0 / 2] = GCC_ANOC_PCIE0_1LANE_M_CLK, > > What is the binding in such case? What exactly do you bind between > driver and DTS? I think what Krzysztof is trying to say here is "the icc-clk API is tragic" and the best solution would be to make it such that the interconnect indices are set explicitly, instead of (master, slave), (master, slave) etc. Does that sound good, Krzysztof? Konrad
On 10/04/2024 13:48, Konrad Dybcio wrote: > > > On 4/10/24 13:15, Krzysztof Kozlowski wrote: >> On 10/04/2024 12:02, Varadarajan Narayanan wrote: >>>> Okay, so what happens if icc-clk way of generating them changes a bit? >>>> It can change, why not, driver implementation is not an ABI. >>>> >>>>> >>>>> 2. These auto-generated id-numbers have to be correctly >>>>> tied to the DT nodes. Else, the relevant clocks may >>>>> not get enabled. >>>> >>>> Sorry, I don't get, how auto generated ID number is tied to DT node. >>>> What DT node? >>> >>> I meant the following usage for the 'interconnects' entry of the >>> consumer peripheral's node. >>> >>> interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>, >>> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ >>> <&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>; >>> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ >>> >>>>> Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and >>>>> one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in >>>>> the below array would create holes. >>>>> >>>>> static int icc_ipq9574_hws[] = { >>>>> [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, >>>>> [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, >>>>> [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, >>>>> [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, >>>>> . . . >>>>> }; >>>>> >>>>> Other Qualcomm drivers don't have this issue and they can >>>>> directly use the MASTER/SLAVE_xxx macros. >>>> >>>> I understand, thanks, yet your last patch keeps adding fake IDs, means >>>> IDs which are not part of ABI. >>>> >>>>> >>>>> As the MASTER_xxx macros cannot be used, have to define a new set >>>>> of macros that can be used for indices in the above array. This >>>>> is the reason for the ICC_BINDING_NAME macros. >>>> >>>> Then maybe fix the driver, instead of adding something which is not an >>>> ABI to bindings and completely skipping the actual ABI. >>> >>> Will remove the ICC_xxx defines from the header. And in the >>> driver will change the declaration as follows. Will that be >>> acceptable? >>> >>> static int icc_ipq9574_hws[] = { >>> [MASTER_ANOC_PCIE0 / 2] = GCC_ANOC_PCIE0_1LANE_M_CLK, >> >> What is the binding in such case? What exactly do you bind between >> driver and DTS? > > I think what Krzysztof is trying to say here is "the icc-clk API is tragic" > and the best solution would be to make it such that the interconnect indices > are set explicitly, instead of (master, slave), (master, slave) etc. > > Does that sound good, Krzysztof? Yes, I think earlier I expressed that icc-clk might needs fixes. The indices you define in the binding must be used by DTS and by the driver. Directly, otherwise it is error-prone and not really an ABI... Best regards, Krzysztof
On Wed, Apr 10, 2024 at 02:01:00PM +0200, Krzysztof Kozlowski wrote: > On 10/04/2024 13:48, Konrad Dybcio wrote: > > > > > > On 4/10/24 13:15, Krzysztof Kozlowski wrote: > >> On 10/04/2024 12:02, Varadarajan Narayanan wrote: > >>>> Okay, so what happens if icc-clk way of generating them changes a bit? > >>>> It can change, why not, driver implementation is not an ABI. > >>>> > >>>>> > >>>>> 2. These auto-generated id-numbers have to be correctly > >>>>> tied to the DT nodes. Else, the relevant clocks may > >>>>> not get enabled. > >>>> > >>>> Sorry, I don't get, how auto generated ID number is tied to DT node. > >>>> What DT node? > >>> > >>> I meant the following usage for the 'interconnects' entry of the > >>> consumer peripheral's node. > >>> > >>> interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>, > >>> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ > >>> <&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>; > >>> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ > >>> > >>>>> Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and > >>>>> one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in > >>>>> the below array would create holes. > >>>>> > >>>>> static int icc_ipq9574_hws[] = { > >>>>> [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, > >>>>> [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, > >>>>> [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, > >>>>> [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, > >>>>> . . . > >>>>> }; > >>>>> > >>>>> Other Qualcomm drivers don't have this issue and they can > >>>>> directly use the MASTER/SLAVE_xxx macros. > >>>> > >>>> I understand, thanks, yet your last patch keeps adding fake IDs, means > >>>> IDs which are not part of ABI. > >>>> > >>>>> > >>>>> As the MASTER_xxx macros cannot be used, have to define a new set > >>>>> of macros that can be used for indices in the above array. This > >>>>> is the reason for the ICC_BINDING_NAME macros. > >>>> > >>>> Then maybe fix the driver, instead of adding something which is not an > >>>> ABI to bindings and completely skipping the actual ABI. > >>> > >>> Will remove the ICC_xxx defines from the header. And in the > >>> driver will change the declaration as follows. Will that be > >>> acceptable? > >>> > >>> static int icc_ipq9574_hws[] = { > >>> [MASTER_ANOC_PCIE0 / 2] = GCC_ANOC_PCIE0_1LANE_M_CLK, > >> > >> What is the binding in such case? What exactly do you bind between > >> driver and DTS? > > > > I think what Krzysztof is trying to say here is "the icc-clk API is tragic" > > and the best solution would be to make it such that the interconnect indices > > are set explicitly, instead of (master, slave), (master, slave) etc. > > > > Does that sound good, Krzysztof? > > Yes, I think earlier I expressed that icc-clk might needs fixes. Ok > The indices you define in the binding must be used by DTS and by the driver. There are 3 drivers in play here. 1. The icc-clk driver 2. The gcc (i.e. the interconnect driver) 3. The consumer peripheral's driver By 'driver' I assume, you mean the icc-clk driver. > Directly, otherwise it is error-prone and not really an ABI... To address this, will modify the icc-clk driver as follows. ========================================== diff --git a/include/linux/interconnect-clk.h b/include/linux/interconnect-clk.h index 5c611a8b0892..9bcee3e9c56c 100644 --- a/include/linux/interconnect-clk.h +++ b/include/linux/interconnect-clk.h @@ -11,6 +11,8 @@ struct device; struct icc_clk_data { struct clk *clk; const char *name; + unsigned int master_id; + unsigned int slave_id; }; diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c index bce946592c98..f788db15cd76 100644 --- a/drivers/interconnect/icc-clk.c +++ b/drivers/interconnect/icc-clk.c @@ -108,7 +108,7 @@ struct icc_provider *icc_clk_register(struct device *dev, for (i = 0, j = 0; i < num_clocks; i++) { qp->clocks[i].clk = data[i].clk; - node = icc_node_create(first_id + j); + node = icc_node_create(first_id + data[i].master_id); if (IS_ERR(node)) { ret = PTR_ERR(node); goto err; @@ -118,10 +118,10 @@ struct icc_provider *icc_clk_register(struct device *dev, node->data = &qp->clocks[i]; icc_node_add(node, provider); /* link to the next node, slave */ - icc_link_create(node, first_id + j + 1); + icc_link_create(node, first_id + data[i].slave_id); onecell->nodes[j++] = node; - node = icc_node_create(first_id + j); + node = icc_node_create(first_id + data[i].slave_id); if (IS_ERR(node)) { ret = PTR_ERR(node); goto err; ========================================== And update the inputs going from gcc-ipq9574.c accordingly to use the MASTER_xxx and SLAVE_xxx defines. Will this be ok? Konrad & Krzysztof kindly let me know. Thanks Varada
On Fri, Apr 12, 2024 at 03:02:47PM +0530, Varadarajan Narayanan wrote: > On Wed, Apr 10, 2024 at 02:01:00PM +0200, Krzysztof Kozlowski wrote: > > On 10/04/2024 13:48, Konrad Dybcio wrote: > > > > > > > > > On 4/10/24 13:15, Krzysztof Kozlowski wrote: > > >> On 10/04/2024 12:02, Varadarajan Narayanan wrote: > > >>>> Okay, so what happens if icc-clk way of generating them changes a bit? > > >>>> It can change, why not, driver implementation is not an ABI. > > >>>> > > >>>>> > > >>>>> 2. These auto-generated id-numbers have to be correctly > > >>>>> tied to the DT nodes. Else, the relevant clocks may > > >>>>> not get enabled. > > >>>> > > >>>> Sorry, I don't get, how auto generated ID number is tied to DT node. > > >>>> What DT node? > > >>> > > >>> I meant the following usage for the 'interconnects' entry of the > > >>> consumer peripheral's node. > > >>> > > >>> interconnects = <&gcc MASTER_ANOC_PCIE0 &gcc SLAVE_ANOC_PCIE0>, > > >>> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ > > >>> <&gcc MASTER_SNOC_PCIE0 &gcc SLAVE_SNOC_PCIE0>; > > >>> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ > > >>> > > >>>>> Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and > > >>>>> one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in > > >>>>> the below array would create holes. > > >>>>> > > >>>>> static int icc_ipq9574_hws[] = { > > >>>>> [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK, > > >>>>> [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK, > > >>>>> [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK, > > >>>>> [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK, > > >>>>> . . . > > >>>>> }; > > >>>>> > > >>>>> Other Qualcomm drivers don't have this issue and they can > > >>>>> directly use the MASTER/SLAVE_xxx macros. > > >>>> > > >>>> I understand, thanks, yet your last patch keeps adding fake IDs, means > > >>>> IDs which are not part of ABI. > > >>>> > > >>>>> > > >>>>> As the MASTER_xxx macros cannot be used, have to define a new set > > >>>>> of macros that can be used for indices in the above array. This > > >>>>> is the reason for the ICC_BINDING_NAME macros. > > >>>> > > >>>> Then maybe fix the driver, instead of adding something which is not an > > >>>> ABI to bindings and completely skipping the actual ABI. > > >>> > > >>> Will remove the ICC_xxx defines from the header. And in the > > >>> driver will change the declaration as follows. Will that be > > >>> acceptable? > > >>> > > >>> static int icc_ipq9574_hws[] = { > > >>> [MASTER_ANOC_PCIE0 / 2] = GCC_ANOC_PCIE0_1LANE_M_CLK, > > >> > > >> What is the binding in such case? What exactly do you bind between > > >> driver and DTS? > > > > > > I think what Krzysztof is trying to say here is "the icc-clk API is tragic" > > > and the best solution would be to make it such that the interconnect indices > > > are set explicitly, instead of (master, slave), (master, slave) etc. > > > > > > Does that sound good, Krzysztof? > > > > Yes, I think earlier I expressed that icc-clk might needs fixes. > > Ok > > > The indices you define in the binding must be used by DTS and by the driver. > > There are 3 drivers in play here. > 1. The icc-clk driver > 2. The gcc (i.e. the interconnect driver) > 3. The consumer peripheral's driver > > By 'driver' I assume, you mean the icc-clk driver. > > > Directly, otherwise it is error-prone and not really an ABI... > > To address this, will modify the icc-clk driver as follows. > > ========================================== > diff --git a/include/linux/interconnect-clk.h b/include/linux/interconnect-clk.h > index 5c611a8b0892..9bcee3e9c56c 100644 > --- a/include/linux/interconnect-clk.h > +++ b/include/linux/interconnect-clk.h > @@ -11,6 +11,8 @@ struct device; > struct icc_clk_data { > struct clk *clk; > const char *name; > + unsigned int master_id; > + unsigned int slave_id; > }; > > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c > index bce946592c98..f788db15cd76 100644 > --- a/drivers/interconnect/icc-clk.c > +++ b/drivers/interconnect/icc-clk.c > @@ -108,7 +108,7 @@ struct icc_provider *icc_clk_register(struct device *dev, > for (i = 0, j = 0; i < num_clocks; i++) { > qp->clocks[i].clk = data[i].clk; > > - node = icc_node_create(first_id + j); > + node = icc_node_create(first_id + data[i].master_id); > if (IS_ERR(node)) { > ret = PTR_ERR(node); > goto err; > @@ -118,10 +118,10 @@ struct icc_provider *icc_clk_register(struct device *dev, > node->data = &qp->clocks[i]; > icc_node_add(node, provider); > /* link to the next node, slave */ > - icc_link_create(node, first_id + j + 1); > + icc_link_create(node, first_id + data[i].slave_id); > onecell->nodes[j++] = node; > > - node = icc_node_create(first_id + j); > + node = icc_node_create(first_id + data[i].slave_id); > if (IS_ERR(node)) { > ret = PTR_ERR(node); > goto err; > ========================================== > > And update the inputs going from gcc-ipq9574.c accordingly > to use the MASTER_xxx and SLAVE_xxx defines. Will this be ok? > > Konrad & Krzysztof kindly let me know. Have addressed these and other comments and posted v8. Please review. Thanks Varada
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml index 944a0ea79cd6..824781cbdf34 100644 --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml @@ -33,6 +33,9 @@ properties: - description: PCIE30 PHY3 pipe clock source - description: USB3 PHY pipe clock source + '#interconnect-cells': + const: 1 + required: - compatible - clocks diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h new file mode 100644 index 000000000000..0b076b0cf880 --- /dev/null +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h @@ -0,0 +1,87 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +#ifndef INTERCONNECT_QCOM_IPQ9574_H +#define INTERCONNECT_QCOM_IPQ9574_H + +#define ICC_ANOC_PCIE0 0 +#define ICC_SNOC_PCIE0 1 +#define ICC_ANOC_PCIE1 2 +#define ICC_SNOC_PCIE1 3 +#define ICC_ANOC_PCIE2 4 +#define ICC_SNOC_PCIE2 5 +#define ICC_ANOC_PCIE3 6 +#define ICC_SNOC_PCIE3 7 +#define ICC_SNOC_USB 8 +#define ICC_ANOC_USB_AXI 9 +#define ICC_NSSNOC_NSSCC 10 +#define ICC_NSSNOC_SNOC_0 11 +#define ICC_NSSNOC_SNOC_1 12 +#define ICC_NSSNOC_PCNOC_1 13 +#define ICC_NSSNOC_QOSGEN_REF 14 +#define ICC_NSSNOC_TIMEOUT_REF 15 +#define ICC_NSSNOC_XO_DCD 16 +#define ICC_NSSNOC_ATB 17 +#define ICC_MEM_NOC_NSSNOC 18 +#define ICC_NSSNOC_MEMNOC 19 +#define ICC_NSSNOC_MEM_NOC_1 20 + +#define ICC_NSSNOC_PPE 0 +#define ICC_NSSNOC_PPE_CFG 1 +#define ICC_NSSNOC_NSS_CSR 2 +#define ICC_NSSNOC_IMEM_QSB 3 +#define ICC_NSSNOC_IMEM_AHB 4 + +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2) +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1) +#define MASTER_SNOC_PCIE0 (ICC_SNOC_PCIE0 * 2) +#define SLAVE_SNOC_PCIE0 ((ICC_SNOC_PCIE0 * 2) + 1) +#define MASTER_ANOC_PCIE1 (ICC_ANOC_PCIE1 * 2) +#define SLAVE_ANOC_PCIE1 ((ICC_ANOC_PCIE1 * 2) + 1) +#define MASTER_SNOC_PCIE1 (ICC_SNOC_PCIE1 * 2) +#define SLAVE_SNOC_PCIE1 ((ICC_SNOC_PCIE1 * 2) + 1) +#define MASTER_ANOC_PCIE2 (ICC_ANOC_PCIE2 * 2) +#define SLAVE_ANOC_PCIE2 ((ICC_ANOC_PCIE2 * 2) + 1) +#define MASTER_SNOC_PCIE2 (ICC_SNOC_PCIE2 * 2) +#define SLAVE_SNOC_PCIE2 ((ICC_SNOC_PCIE2 * 2) + 1) +#define MASTER_ANOC_PCIE3 (ICC_ANOC_PCIE3 * 2) +#define SLAVE_ANOC_PCIE3 ((ICC_ANOC_PCIE3 * 2) + 1) +#define MASTER_SNOC_PCIE3 (ICC_SNOC_PCIE3 * 2) +#define SLAVE_SNOC_PCIE3 ((ICC_SNOC_PCIE3 * 2) + 1) +#define MASTER_USB (ICC_USB * 2) +#define SLAVE_USB ((ICC_USB * 2) + 1) +#define MASTER_USB_AXI (ICC_USB_AXI * 2) +#define SLAVE_USB_AXI ((ICC_USB_AXI * 2) + 1) +#define MASTER_NSSNOC_NSSCC (ICC_NSSNOC_NSSCC * 2) +#define SLAVE_NSSNOC_NSSCC ((ICC_NSSNOC_NSSCC * 2) + 1) +#define MASTER_NSSNOC_SNOC_0 (ICC_NSSNOC_SNOC_0 * 2) +#define SLAVE_NSSNOC_SNOC_0 ((ICC_NSSNOC_SNOC_0 * 2) + 1) +#define MASTER_NSSNOC_SNOC_1 (ICC_NSSNOC_SNOC_1 * 2) +#define SLAVE_NSSNOC_SNOC_1 ((ICC_NSSNOC_SNOC_1 * 2) + 1) +#define MASTER_NSSNOC_PCNOC_1 (ICC_NSSNOC_PCNOC_1 * 2) +#define SLAVE_NSSNOC_PCNOC_1 ((ICC_NSSNOC_PCNOC_1 * 2) + 1) +#define MASTER_NSSNOC_QOSGEN_REF (ICC_NSSNOC_QOSGEN_REF * 2) +#define SLAVE_NSSNOC_QOSGEN_REF ((ICC_NSSNOC_QOSGEN_REF * 2) + 1) +#define MASTER_NSSNOC_TIMEOUT_REF (ICC_NSSNOC_TIMEOUT_REF * 2) +#define SLAVE_NSSNOC_TIMEOUT_REF ((ICC_NSSNOC_TIMEOUT_REF * 2) + 1) +#define MASTER_NSSNOC_XO_DCD (ICC_NSSNOC_XO_DCD * 2) +#define SLAVE_NSSNOC_XO_DCD ((ICC_NSSNOC_XO_DCD * 2) + 1) +#define MASTER_NSSNOC_ATB (ICC_NSSNOC_ATB * 2) +#define SLAVE_NSSNOC_ATB ((ICC_NSSNOC_ATB * 2) + 1) +#define MASTER_MEM_NOC_NSSNOC (ICC_MEM_NOC_NSSNOC * 2) +#define SLAVE_MEM_NOC_NSSNOC ((ICC_MEM_NOC_NSSNOC * 2) + 1) +#define MASTER_NSSNOC_MEMNOC (ICC_NSSNOC_MEMNOC * 2) +#define SLAVE_NSSNOC_MEMNOC ((ICC_NSSNOC_MEMNOC * 2) + 1) +#define MASTER_NSSNOC_MEM_NOC_1 (ICC_NSSNOC_MEM_NOC_1 * 2) +#define SLAVE_NSSNOC_MEM_NOC_1 ((ICC_NSSNOC_MEM_NOC_1 * 2) + 1) + +#define MASTER_NSSNOC_PPE (ICC_NSSNOC_PPE * 2) +#define SLAVE_NSSNOC_PPE ((ICC_NSSNOC_PPE * 2) + 1) +#define MASTER_NSSNOC_PPE_CFG (ICC_NSSNOC_PPE_CFG * 2) +#define SLAVE_NSSNOC_PPE_CFG ((ICC_NSSNOC_PPE_CFG * 2) + 1) +#define MASTER_NSSNOC_NSS_CSR (ICC_NSSNOC_NSS_CSR * 2) +#define SLAVE_NSSNOC_NSS_CSR ((ICC_NSSNOC_NSS_CSR * 2) + 1) +#define MASTER_NSSNOC_IMEM_QSB (ICC_NSSNOC_IMEM_QSB * 2) +#define SLAVE_NSSNOC_IMEM_QSB ((ICC_NSSNOC_IMEM_QSB * 2) + 1) +#define MASTER_NSSNOC_IMEM_AHB (ICC_NSSNOC_IMEM_AHB * 2) +#define SLAVE_NSSNOC_IMEM_AHB ((ICC_NSSNOC_IMEM_AHB * 2) + 1) + +#endif /* INTERCONNECT_QCOM_IPQ9574_H */
Add interconnect-cells to clock provider so that it can be used as icc provider. Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip interfaces. This will be used by the gcc-ipq9574 driver that will for providing interconnect services using the icc-clk framework. Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> --- v7: Fix macro names to be consistent with other bindings v6: Removed Reviewed-by: Krzysztof Kozlowski Redefine the bindings such that driver and DT can share them v3: Squash Documentation/ and include/ changes into same patch qcom,ipq9574.h Move 'first id' to clock driver --- .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 + .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++ 2 files changed, 90 insertions(+) create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h