On 10/14/2026 7:31 PM, Krzysztof Kozlowski wrote:
On Wed, Oct 14, 2026 at 12:38:16PM +0800, Yongxing Mou wrote:
Kaanapali (SM8850) has two display GDSCs. CORE_GDSC supplies shared
MDSS hardware and most of the DPU, while INT2 GDSC supplies the
VIG2/VIG3/DMA5 source pipes. Without INT2 GDSC, these source pipes
remain inaccessible.
Describe CORE and INT2 as power domains of the DPU device, matching
the hardware partitioning. INT2 only supplies DPU-local source pipes,
while CORE also remains attached to the parent MDSS device because it
supplies shared MDSS hardware. DPU performance-state votes on CORE are
propagated through the genpd hierarchy to its parent MMCX domain.
Restrict the two-domain schema to the Kaanapali DPU compatible, so other
platforms sharing qcom,sm8650-dpu.yaml retain the existing single
power-domain constraint.
Signed-off-by: Yongxing Mou <[email protected]>
---
.../devicetree/bindings/display/msm/dpu-common.yaml | 19 +++++++++++++++++--
.../bindings/display/msm/qcom,kaanapali-mdss.yaml | 4 +++-
.../bindings/display/msm/qcom,sm8650-dpu.yaml | 21 +++++++++++++++++++++
3 files changed, 41 insertions(+), 3 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
No, widest constraints always stay here. Look at other bindings.
Got it. Thanks. So here mean allowing up to two power domains in
dpu-common.yaml, requiring two for Kaanapali in qcom,sm8650-dpu.yaml,
and adding maxItems: 1 to the other DPU bindings to preserve their
existing constraints?>>
operating-points-v2: true
opp-table:
@@ -53,4 +52,20 @@ required:
- operating-points-v2
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,kaanapali-dpu
There is no such compatible. Open this file and point me to it. Why are
you adding this compatible to common schema? Is there any prior art
doing something like this?
Thanks for pointing this out. I will move the Kaanapali-specific
constraint to qcom,sm8650-dpu.yaml, where qcom,kaanapali-dpu is defined.
Best regards,
Krzysztof
