[PATCH v2 07/11] dt-bindings: clock: qcom: document the Kaanapali GPU Clock Controller
Krzysztof Kozlowski
krzk at kernel.org
Fri Dec 19 04:56:02 PST 2025
On 19/12/2025 11:39, Taniya Das wrote:
>
>
> On 12/17/2025 7:24 PM, Krzysztof Kozlowski wrote:
>> On 17/12/2025 14:21, Konrad Dybcio wrote:
>>> On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote:
>>>> On 17/12/2025 10:32, Taniya Das wrote:
>>>>>>>
>>>>>>> We would like to leverage the existing common clock driver(GDSC) code to
>>>>>>
>>>>>> Fix the driver code if it cannot handle other cells. Your drivers do not
>>>>>> matter for choices made in bindings.
>>>>>>
>>>>>
>>>>> As it is still a clock controller from hardware design and in SW I will
>>>>> be map the entire hardware region and this way this clock controller
>>>>> will also be aligned to the existing clock controllers and keep the
>>>>> #power-domain-cells = <1> as other CCs.
>>>>
>>>> I don't see how this resolves my comment.
>>>
>>> Spanning the entire 0x6000-long block will remove your worry about this
>>> description only being 2-register-wide
>>
>> But that was not the comment here. Taniya replied under comment about
>> cells. We are not discussing here some other things...
>>
>
> I will review and add support for handling #power-domain-cells = <0> in
> our common code of clock & gdsc. However, the initial intent was to keep
> the GDSC phandle uniform across chipsets as this is a clock controller
> by hardware design, which is why #power-domain-cells was originally set
> to <1>.
Having cells=0 or =2 or =3 does not change "as this is a clock
controller by hardware design" at all.
I do not see any of these arguments relevant to discussion.
Best regards,
Krzysztof
More information about the linux-arm-kernel
mailing list