Re: [PATCH v2 1/3] dt-bindings: display: msm: Add INT2 GDSC to Kaanapali DPU

[Yongxing Mou <yongxing.mou@oss.qualcomm.com>]

On 10/5/2026 9:02 AM, Dmitry Baryshkov wrote:
> On Tue, Sep 15, 2026 at 05:27:48PM +0800, Yongxing Mou wrote:
>> Kaanapali (SM8850) has an additional INT2 GDSC that powers a subset
>> of the DPU source pipes (VIG2/VIG3/DMA5), on top of the CORE_GDSC
>> that powers the rest of the MDSS hardware.
>>
>> Describe INT2 GDSC as an additional power domain of the DPU device
>> rather than of the whole MDSS, since it only supplies DPU-local
>> source pipes. Restrict the schema change to the Kaanapali DPU
>> compatible via an if/then, so other platforms sharing
>> qcom,sm8650-dpu.yaml (which don't have an INT2 GDSC) keep the
>> existing single power-domain constraint.
>>
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> ---
>>   .../bindings/display/msm/dpu-common.yaml           | 19 ++++++++++++++++--
>>   .../bindings/display/msm/qcom,sm8650-dpu.yaml      | 23 ++++++++++++++++++++++
>>   2 files changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
>> index 3f953aa5e694..19b791a857b5 100644
>> --- a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
>> +++ b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
>> @@ -25,8 +25,7 @@ properties:
>>     interrupts:
>>       maxItems: 1
>>   
>> -  power-domains:
>> -    maxItems: 1
>> +  power-domains: true
>>   
>>     operating-points-v2: true
>>     opp-table:
>> @@ -53,4 +52,20 @@ required:
>>     - operating-points-v2
>>     - ports
>>   
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: qcom,kaanapali-dpu
>> +    then:
>> +      properties:
>> +        power-domains:
>> +          minItems: 2
>> +          maxItems: 2
>> +    else:
>> +      properties:
>> +        power-domains:
>> +          maxItems: 1
>> +
>>   additionalProperties: true
>> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml
>> index aa0cf0ec5b93..88aa71d2b912 100644
>> --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml
>> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml
>> @@ -61,6 +61,29 @@ required:
>>     - clocks
>>     - clock-names
>>   
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: qcom,kaanapali-dpu
>> +    then:
>> +      properties:
>> +        power-domains:
>> +          items:
>> +            - description: MMCX power domain
>> +            - description: INT2 GDSC power domain
>> +
>> +        power-domain-names:
>> +          minItems: 2
>> +          maxItems: 2
>> +          items:
>> +            - const: mmcx
>> +            - const: int2
> 
> Nit: I'd suggest more generic names here. If the next platform switches
> from "mmcx" to some other domain, while keeping the split architecture,
> the name becomes unapplicable (in the past we have seen platforms using
> CX instead of MMCX). What about using names like "core", "int2"?
> 
Agreed, using "mmcx" would be too provider-specific, as the DPU 
performance domain can be CX on other platforms.

However, "core" might be confusing here because DISP_CC_MDSS_CORE_GDSC 
is already attached to the parent MDSS device. The first domain on the 
DPU is used for OPP performance-state voting, so would "perf" and "int2" 
be clearer generic names?
>> +
>> +      required:
>> +        - power-domain-names
>> +
>>   unevaluatedProperties: false
>>   
>>   examples:
>>
>> -- 
>> 2.43.0
>>
>