Re: [PATCH v2 1/6] dt-bindings: clock: qcom: Add GPU clocks for QCS8300

[Krzysztof Kozlowski <krzk@kernel.org>]

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