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