[PATCH v2 07/11] dt-bindings: clock: qcom: document the Kaanapali GPU Clock Controller
Taniya Das
taniya.das at oss.qualcomm.com
Wed Dec 3 22:49:28 PST 2025
On 11/26/2025 3:05 PM, Krzysztof Kozlowski wrote:
> On Tue, Nov 25, 2025 at 11:15:16PM +0530, Taniya Das wrote:
>> Add bindings documentation for the Kaanapali Graphics Clock and Graphics
>> power domain Controller.
>>
>> Signed-off-by: Jingyi Wang <jingyi.wang at oss.qualcomm.com>
>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>
>> Signed-off-by: Taniya Das <taniya.das at oss.qualcomm.com>
>> ---
>> .../bindings/clock/qcom,kaanapali-gxclkctl.yaml | 63 ++++++++++++++++++++++
>> .../bindings/clock/qcom,sm8450-gpucc.yaml | 2 +
>> include/dt-bindings/clock/qcom,kaanapali-gpucc.h | 47 ++++++++++++++++
>> .../dt-bindings/clock/qcom,kaanapali-gxclkctl.h | 12 +++++
>> 4 files changed, 124 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..31398aec839d88007c9f1de7e1a248beae826640
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
>> @@ -0,0 +1,63 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/qcom,kaanapali-gxclkctl.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm Graphics power domain Controller on Kaanapali
>
> "Power Domain"
>
will fix in the next patch.
>> +
>> +maintainers:
>> + - Taniya Das <taniya.das at oss.qualcomm.com>
>> +
>> +description: |
>> + Qualcomm graphics power domain control module provides the power
>> + domains on Qualcomm SoCs. This module exposes the GDSC power domain
>> + which helps the recovery of Graphics subsystem.
>> +
>> + See also::
>
> Just one ':'
>
My bad, will fix it in the next series.
>> + include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - qcom,kaanapali-gxclkctl
>> +
>> + power-domains:
>> + description:
>> + Power domains required for the clock controller to operate
>> + items:
>> + - description: GFX power domain
>> + - description: GMXC power domain
>> + - description: GPUCC(CX) power domain
>> +
>> + '#power-domain-cells':
>
> Power domain controllers do not belong to clocks, so this is:
> 1. Misplaced - wrong folder
> 2. Probably wrongly named. gxclkctl sounds like clock controller, but
> this is domain controller?
>
The GFXCLKCTL is actually a clock controller which has PLLs, clocks and
Power domains (GDSC), but the requirement here is to use the GDSC from
the clock controller to recover the GPU firmware in case of any
failure/hangs. The rest of the resources of the clock controller are
being used by the firmware of GPU. The GDSC is a clock controller
resource and modeled from the clock controller drivers across chipsets.
>> + const: 1
>> +
>> + reg:
>> + maxItems: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - power-domains
>> + - '#power-domain-cells'
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + clock-controller at 3d68024 {
>> + compatible = "qcom,kaanapali-gxclkctl";
>> + reg = <0 0x3d68024 0x0 0x8>;
>
> Keep consistent hex, so first 0 -> 0x0.
Sure, will fix this.
> But the problem is that you defined a device for two registers,
> basically one domain. I have doubts now whether this is complete and
> real device.
>
As the Linux GPU driver requires only the GDSC, I have mapped the region
which is required by the clock controller driver. If required, the
entire region can be mapped as well.
>> + power-domains = <&rpmhpd RPMHPD_GFX>,
>> + <&rpmhpd RPMHPD_GMXC>,
>> + <&gpucc 0>;
>> + #power-domain-cells = <1>;
>
> And cells 1 makes no sense in such case.
>
We would like to leverage the existing common clock driver(GDSC) code to
register the power-domains and also maintain uniformity across chipsets
and consistency in consumer GDSC phandle usage.
--
Thanks,
Taniya Das
More information about the linux-arm-kernel
mailing list