On 10.02.2025 10:33 AM, Taniya Das wrote:
>
>
> On 2/6/2025 5:12 PM, Konrad Dybcio wrote:
>> On 4.02.2025 6:33 PM, Taniya Das wrote:
>>>
>>>
>>> On 2/3/2025 7:44 PM, Konrad Dybcio wrote:
>>>> On 19.01.2025 1:00 PM, Taniya Das wrote:
>>>>> Add support for video, camera, display and gpu clock controller nodes
>>>>> for QCS615 platform.
>>>>>
>>>>> Signed-off-by: Taniya Das <quic_tdas@xxxxxxxxxxx>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/qcs615.dtsi | 51 ++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 51 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi
>>>>> index f4abfad474ea62dea13d05eb874530947e1e8d3e..9d537019437c5202c4d398eecd0ce2a991083175 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/qcs615.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi
>>>>> @@ -3,7 +3,11 @@
>>>>> * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
>>>>> */
>>>>> +#include <dt-bindings/clock/qcom,qcs615-camcc.h>
>>>>> +#include <dt-bindings/clock/qcom,qcs615-dispcc.h>
>>>>> #include <dt-bindings/clock/qcom,qcs615-gcc.h>
>>>>> +#include <dt-bindings/clock/qcom,qcs615-gpucc.h>
>>>>> +#include <dt-bindings/clock/qcom,qcs615-videocc.h>
>>>>> #include <dt-bindings/clock/qcom,rpmh.h>
>>>>> #include <dt-bindings/dma/qcom-gpi.h>
>>>>> #include <dt-bindings/interconnect/qcom,icc.h>
>>>>> @@ -1418,6 +1422,18 @@ data-pins {
>>>>> };
>>>>> };
>>>>> + gpucc: clock-controller@5090000 {
>>>>> + compatible = "qcom,qcs615-gpucc";
>>>>> + reg = <0 0x05090000 0 0x9000>;
>>>>> +
>>>>> + clocks = <&rpmhcc RPMH_CXO_CLK>,
>>>>> + <&gcc GPLL0>;
>>>>
>>>> This would normally be GCC_GPU_GPLL0_(DIV_)CLK_SRC, is this intentional?
>>>>
>>>
>>> Yes, Konard, but on QCS615 GPLL0 is connected and not the GCC_GPU_GPLL0 sources.
>>
>> It looks like you're right.. if I'm looking in the right place, the _GPU_ ones
>> are not connected anywhere..
>>
>> It also seems like the reset state of the _GPU_ ones is OFF (as expected),
>> should we remove them from the GCC driver to reduce confusion?
>>
>
> Yeah I understand it might confuse, but I would like to keep them as the code will match the clocks present in the hardware.
Alright, let's just keep that as is
Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
Konrad
