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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxxxxx

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






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux