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