The QCS8300 GPU clock controller is mostly identical to SA8775P, but
QCS8300 has few additional clocks and minor differences. Hence, reuse
SA8775P gpucc bindings and add additional clocks required for QCS8300.
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
---
Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 1 +
include/dt-bindings/clock/qcom,sa8775p-gpucc.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 0858fd635282..b2b8a1e0297f 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -27,6 +27,7 @@ description: |
properties:
compatible:
enum:
+ - qcom,qcs8300-gpucc
- qcom,sdm845-gpucc
- qcom,sa8775p-gpucc
- qcom,sc7180-gpucc
diff --git a/include/dt-bindings/clock/qcom,sa8775p-gpucc.h b/include/dt-bindings/clock/qcom,sa8775p-gpucc.h
index a5fd784b1ea2..54eaaf1c4e52 100644
--- a/include/dt-bindings/clock/qcom,sa8775p-gpucc.h
+++ b/include/dt-bindings/clock/qcom,sa8775p-gpucc.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
/*
- * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022, 2024 Qualcomm Innovation Center, Inc. All rights reserved.
* Copyright (c) 2023, Linaro Limited
*/
@@ -31,6 +31,8 @@
#define GPU_CC_MEMNOC_GFX_CLK 20
#define GPU_CC_SLEEP_CLK 21
#define GPU_CC_XO_CLK_SRC 22
+#define GPU_CC_CX_ACCU_SHIFT_CLK 23
+#define GPU_CC_GX_ACCU_SHIFT_CLK 24
/* GPU_CC resets */
#define GPUCC_GPU_CC_ACD_BCR 0
--
2.25.1On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: > The QCS8300 GPU clock controller is mostly identical to SA8775P, but > QCS8300 has few additional clocks and minor differences. Hence, reuse > SA8775P gpucc bindings and add additional clocks required for QCS8300. IIUC, these clocks are not valid for SA8775p. How do we deal with such cases for other Qualcomm SoCs? Best regards, Krzysztof
On 10/26/24 15:20, Krzysztof Kozlowski wrote:
> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote:
>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but
>> QCS8300 has few additional clocks and minor differences. Hence, reuse
>> SA8775P gpucc bindings and add additional clocks required for QCS8300.
>
> IIUC, these clocks are not valid for SA8775p. How do we deal with such
> cases for other Qualcomm SoCs?
>
It always possible to add a new platform specific header file and
include the old one.
For reference see commit a6a61b9701d1 ("dt-bindings: clock: qcom: Add
SM8650 video clock controller"), I believe that's the preferred way
of adding new platform clocks whenever technically possible.
--
Best wishes,
Vladimir
On 10/30/2024 4:29 PM, Vladimir Zapolskiy wrote:
> On 10/26/24 15:20, Krzysztof Kozlowski wrote:
>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote:
>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but
>>> QCS8300 has few additional clocks and minor differences. Hence, reuse
>>> SA8775P gpucc bindings and add additional clocks required for QCS8300.
>>
>> IIUC, these clocks are not valid for SA8775p. How do we deal with such
>> cases for other Qualcomm SoCs?
>>
>
> It always possible to add a new platform specific header file and
> include the old one.
>
> For reference see commit a6a61b9701d1 ("dt-bindings: clock: qcom: Add
> SM8650 video clock controller"), I believe that's the preferred way
> of adding new platform clocks whenever technically possible.
>
Sure, I will follow the same approach as the commit a6a61b9701d1 and
post next series.
Thanks,
Imran
> --
> Best wishes,
> Vladimir
On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: > On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >> QCS8300 has few additional clocks and minor differences. Hence, reuse >> SA8775P gpucc bindings and add additional clocks required for QCS8300. > > IIUC, these clocks are not valid for SA8775p. How do we deal with such > cases for other Qualcomm SoCs? > These newly added clocks are not applicable to SA8755P. In the gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, ensuring they are not registered to the CCF. Thanks, Imran > Best regards, > Krzysztof >
On 28/10/2024 06:15, Imran Shaik wrote: > > > On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >> >> IIUC, these clocks are not valid for SA8775p. How do we deal with such >> cases for other Qualcomm SoCs? >> > > These newly added clocks are not applicable to SA8755P. In the > gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, > ensuring they are not registered to the CCF. I meant bindings. And existing practice. Best regards, Krzysztof
On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: > On 28/10/2024 06:15, Imran Shaik wrote: >> >> >> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >>> >>> IIUC, these clocks are not valid for SA8775p. How do we deal with such >>> cases for other Qualcomm SoCs? >>> >> >> These newly added clocks are not applicable to SA8755P. In the >> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, >> ensuring they are not registered to the CCF. > > I meant bindings. And existing practice. > In the bindings, the same approach is followed in other Qualcomm SoCs as well, where additional clocks are added to the existing identical SoC’s bindings. https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com Thanks, Imran > Best regards, > Krzysztof >
On 29/10/2024 10:23, Imran Shaik wrote: > > > On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: >> On 28/10/2024 06:15, Imran Shaik wrote: >>> >>> >>> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >>>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>>>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >>>> >>>> IIUC, these clocks are not valid for SA8775p. How do we deal with such >>>> cases for other Qualcomm SoCs? >>>> >>> >>> These newly added clocks are not applicable to SA8755P. In the >>> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, >>> ensuring they are not registered to the CCF. >> >> I meant bindings. And existing practice. >> > > In the bindings, the same approach is followed in other Qualcomm SoCs as > well, where additional clocks are added to the existing identical SoC’s > bindings. > > https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com Exactly, defines are very different, so no, it is not the same approach. Best regards, Krzysztof
On 10/29/2024 3:06 PM, Krzysztof Kozlowski wrote: > On 29/10/2024 10:23, Imran Shaik wrote: >> >> >> On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: >>> On 28/10/2024 06:15, Imran Shaik wrote: >>>> >>>> >>>> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >>>>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>>>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>>>>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>>>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >>>>> >>>>> IIUC, these clocks are not valid for SA8775p. How do we deal with such >>>>> cases for other Qualcomm SoCs? >>>>> >>>> >>>> These newly added clocks are not applicable to SA8755P. In the >>>> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, >>>> ensuring they are not registered to the CCF. >>> >>> I meant bindings. And existing practice. >>> >> >> In the bindings, the same approach is followed in other Qualcomm SoCs as >> well, where additional clocks are added to the existing identical SoC’s >> bindings. >> >> https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com > > Exactly, defines are very different, so no, it is not the same approach. > I believe the QCS8300 approach is same as that of SM8475. In the SM8475 SoC, GPLL2 and GPLL3 are the additional clock bindings compared to the SM8450. Similarly, in the QCS8300, the GPU_CC_*_ACCU_SHIFT_CLK clock bindings are additional to the SA8775P. We are also following this approach across all SoCs in the downstream msm-kernel as well. Please let me know if I am missing anything here. Thanks, Imran > Best regards, > Krzysztof >
On 30/10/2024 07:59, Imran Shaik wrote: > > > On 10/29/2024 3:06 PM, Krzysztof Kozlowski wrote: >> On 29/10/2024 10:23, Imran Shaik wrote: >>> >>> >>> On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: >>>> On 28/10/2024 06:15, Imran Shaik wrote: >>>>> >>>>> >>>>> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >>>>>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>>>>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>>>>>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>>>>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >>>>>> >>>>>> IIUC, these clocks are not valid for SA8775p. How do we deal with such >>>>>> cases for other Qualcomm SoCs? >>>>>> >>>>> >>>>> These newly added clocks are not applicable to SA8755P. In the >>>>> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, >>>>> ensuring they are not registered to the CCF. >>>> >>>> I meant bindings. And existing practice. >>>> >>> >>> In the bindings, the same approach is followed in other Qualcomm SoCs as >>> well, where additional clocks are added to the existing identical SoC’s >>> bindings. >>> >>> https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com >> >> Exactly, defines are very different, so no, it is not the same approach. >> > > I believe the QCS8300 approach is same as that of SM8475. In the SM8475 > SoC, GPLL2 and GPLL3 are the additional clock bindings compared to the > SM8450. Similarly, in the QCS8300, the GPU_CC_*_ACCU_SHIFT_CLK clock > bindings are additional to the SA8775P. > > We are also following this approach across all SoCs in the downstream > msm-kernel as well. > > Please let me know if I am missing anything here. Not sure, please take the same approach as SM8475, not a different one. Best regards, Krzysztof
On Wed, Oct 30, 2024 at 08:30:59AM +0100, Krzysztof Kozlowski wrote: > On 30/10/2024 07:59, Imran Shaik wrote: > > > > > > On 10/29/2024 3:06 PM, Krzysztof Kozlowski wrote: > >> On 29/10/2024 10:23, Imran Shaik wrote: > >>> > >>> > >>> On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: > >>>> On 28/10/2024 06:15, Imran Shaik wrote: > >>>>> > >>>>> > >>>>> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: > >>>>>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: > >>>>>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but > >>>>>>> QCS8300 has few additional clocks and minor differences. Hence, reuse > >>>>>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. > >>>>>> > >>>>>> IIUC, these clocks are not valid for SA8775p. How do we deal with such > >>>>>> cases for other Qualcomm SoCs? > >>>>>> > >>>>> > >>>>> These newly added clocks are not applicable to SA8755P. In the > >>>>> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, > >>>>> ensuring they are not registered to the CCF. > >>>> > >>>> I meant bindings. And existing practice. > >>>> > >>> > >>> In the bindings, the same approach is followed in other Qualcomm SoCs as > >>> well, where additional clocks are added to the existing identical SoC’s > >>> bindings. > >>> > >>> https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com > >> > >> Exactly, defines are very different, so no, it is not the same approach. > >> > > > > I believe the QCS8300 approach is same as that of SM8475. In the SM8475 > > SoC, GPLL2 and GPLL3 are the additional clock bindings compared to the > > SM8450. Similarly, in the QCS8300, the GPU_CC_*_ACCU_SHIFT_CLK clock > > bindings are additional to the SA8775P. > > > > We are also following this approach across all SoCs in the downstream > > msm-kernel as well. > > > > Please let me know if I am missing anything here. > > Not sure, please take the same approach as SM8475, not a different one. Just for my understanding, are you proposing to prefix the platform-specific defines with platform name (like it was done for SM8475)? -- With best wishes Dmitry
On 30/10/2024 12:23, Dmitry Baryshkov wrote: > On Wed, Oct 30, 2024 at 08:30:59AM +0100, Krzysztof Kozlowski wrote: >> On 30/10/2024 07:59, Imran Shaik wrote: >>> >>> >>> On 10/29/2024 3:06 PM, Krzysztof Kozlowski wrote: >>>> On 29/10/2024 10:23, Imran Shaik wrote: >>>>> >>>>> >>>>> On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: >>>>>> On 28/10/2024 06:15, Imran Shaik wrote: >>>>>>> >>>>>>> >>>>>>> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >>>>>>>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>>>>>>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>>>>>>>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>>>>>>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >>>>>>>> >>>>>>>> IIUC, these clocks are not valid for SA8775p. How do we deal with such >>>>>>>> cases for other Qualcomm SoCs? >>>>>>>> >>>>>>> >>>>>>> These newly added clocks are not applicable to SA8755P. In the >>>>>>> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, >>>>>>> ensuring they are not registered to the CCF. >>>>>> >>>>>> I meant bindings. And existing practice. >>>>>> >>>>> >>>>> In the bindings, the same approach is followed in other Qualcomm SoCs as >>>>> well, where additional clocks are added to the existing identical SoC’s >>>>> bindings. >>>>> >>>>> https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com >>>> >>>> Exactly, defines are very different, so no, it is not the same approach. >>>> >>> >>> I believe the QCS8300 approach is same as that of SM8475. In the SM8475 >>> SoC, GPLL2 and GPLL3 are the additional clock bindings compared to the >>> SM8450. Similarly, in the QCS8300, the GPU_CC_*_ACCU_SHIFT_CLK clock >>> bindings are additional to the SA8775P. >>> >>> We are also following this approach across all SoCs in the downstream >>> msm-kernel as well. >>> >>> Please let me know if I am missing anything here. >> >> Not sure, please take the same approach as SM8475, not a different one. > > Just for my understanding, are you proposing to prefix the > platform-specific defines with platform name (like it was done for > SM8475)? Yes. Maybe SM8475 did something more, so let's take similar approach. Best regards, Krzysztof
On 10/30/2024 1:00 PM, Krzysztof Kozlowski wrote: > On 30/10/2024 07:59, Imran Shaik wrote: >> >> >> On 10/29/2024 3:06 PM, Krzysztof Kozlowski wrote: >>> On 29/10/2024 10:23, Imran Shaik wrote: >>>> >>>> >>>> On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: >>>>> On 28/10/2024 06:15, Imran Shaik wrote: >>>>>> >>>>>> >>>>>> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >>>>>>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>>>>>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>>>>>>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>>>>>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >>>>>>> >>>>>>> IIUC, these clocks are not valid for SA8775p. How do we deal with such >>>>>>> cases for other Qualcomm SoCs? >>>>>>> >>>>>> >>>>>> These newly added clocks are not applicable to SA8755P. In the >>>>>> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, >>>>>> ensuring they are not registered to the CCF. >>>>> >>>>> I meant bindings. And existing practice. >>>>> >>>> >>>> In the bindings, the same approach is followed in other Qualcomm SoCs as >>>> well, where additional clocks are added to the existing identical SoC’s >>>> bindings. >>>> >>>> https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com >>> >>> Exactly, defines are very different, so no, it is not the same approach. >>> >> >> I believe the QCS8300 approach is same as that of SM8475. In the SM8475 >> SoC, GPLL2 and GPLL3 are the additional clock bindings compared to the >> SM8450. Similarly, in the QCS8300, the GPU_CC_*_ACCU_SHIFT_CLK clock >> bindings are additional to the SA8775P. >> >> We are also following this approach across all SoCs in the downstream >> msm-kernel as well. >> >> Please let me know if I am missing anything here. > > Not sure, please take the same approach as SM8475, not a different one. > Yes, it is the same approach as SM8475. Thanks, Imran > Best regards, > Krzysztof >
On 30/10/2024 11:14, Imran Shaik wrote: > > > On 10/30/2024 1:00 PM, Krzysztof Kozlowski wrote: >> On 30/10/2024 07:59, Imran Shaik wrote: >>> >>> >>> On 10/29/2024 3:06 PM, Krzysztof Kozlowski wrote: >>>> On 29/10/2024 10:23, Imran Shaik wrote: >>>>> >>>>> >>>>> On 10/28/2024 12:35 PM, Krzysztof Kozlowski wrote: >>>>>> On 28/10/2024 06:15, Imran Shaik wrote: >>>>>>> >>>>>>> >>>>>>> On 10/26/2024 5:50 PM, Krzysztof Kozlowski wrote: >>>>>>>> On Thu, Oct 24, 2024 at 07:01:14PM +0530, Imran Shaik wrote: >>>>>>>>> The QCS8300 GPU clock controller is mostly identical to SA8775P, but >>>>>>>>> QCS8300 has few additional clocks and minor differences. Hence, reuse >>>>>>>>> SA8775P gpucc bindings and add additional clocks required for QCS8300. >>>>>>>> >>>>>>>> IIUC, these clocks are not valid for SA8775p. How do we deal with such >>>>>>>> cases for other Qualcomm SoCs? >>>>>>>> >>>>>>> >>>>>>> These newly added clocks are not applicable to SA8755P. In the >>>>>>> gpucc-sa8775p driver, these clocks are marked to NULL for the SA8755P, >>>>>>> ensuring they are not registered to the CCF. >>>>>> >>>>>> I meant bindings. And existing practice. >>>>>> >>>>> >>>>> In the bindings, the same approach is followed in other Qualcomm SoCs as >>>>> well, where additional clocks are added to the existing identical SoC’s >>>>> bindings. >>>>> >>>>> https://lore.kernel.org/r/20240818204348.197788-2-danila@jiaxyga.com >>>> >>>> Exactly, defines are very different, so no, it is not the same approach. >>>> >>> >>> I believe the QCS8300 approach is same as that of SM8475. In the SM8475 >>> SoC, GPLL2 and GPLL3 are the additional clock bindings compared to the >>> SM8450. Similarly, in the QCS8300, the GPU_CC_*_ACCU_SHIFT_CLK clock >>> bindings are additional to the SA8775P. >>> >>> We are also following this approach across all SoCs in the downstream >>> msm-kernel as well. >>> >>> Please let me know if I am missing anything here. >> >> Not sure, please take the same approach as SM8475, not a different one. >> > > Yes, it is the same approach as SM8475. I already said: "Exactly, defines are very different, so no, it is not the same approach." and this discussion leads nowhere. Don't answer with useless responses just so reviewer will go away. NAK. I am going away. Best regards, Krzysztof
© 2016 - 2024 Red Hat, Inc.