From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5266B3A6EE9 for ; Mon, 8 Jun 2026 09:42:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780911764; cv=none; b=O0E+GxP+4YOejiK+fPNBwB51cG2dlpD6Y5sHCdZArjMaMLLJfK9/Z+FvoDBU3Hitjq59TUHu80LHjHRJVMyqL5j78PfPzcvwjISBhAsxK1LAtTwjMqrctyw5keMwk99WsQJEolQVRAx+JLq1lz2SFDdiN2B1Hy+GmdDsnEXnTx4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780911764; c=relaxed/simple; bh=vltzLVxrse6gylrYCArZ9MrsY1oyQjqTO12LN6Gs5Dg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qEeG8IcY04VV0Jpvy64vflaPVz8dlQLGnwflkv20yjAl74pI1tCmprgWfxACsvfWS0OQxS6MBvyikT/QAt+sIHGRznlvN1H7yJc60sJ1RL9MREEFNH2TYR78zLLTbGRfKFh7iLMV55CQR3+4IIFuGPSDc2JL7s2U565YGlU1O4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EucrTqp3; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EucrTqp3" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-84232e83ca9so1702763b3a.2 for ; Mon, 08 Jun 2026 02:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780911762; x=1781516562; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=K89RrwpcqLo8zDg2OvFefmB2AQCgF8PACyQq7p8WH+I=; b=EucrTqp3pLp81A1TqAorG7Hd7G6z6+UUt16s0pLYnZcNJbPgq1P9xHUbsmCW1Zn/KL VGXJkebwHM8ObyV8D9g7KayExl3wn2dk6iW/V6tdDdv5IKRQlpvdBJm5I5koW8F6G57i pu3pGLEoI4QbKWhOGL9QAMpa2ccorUQ3yPdqubqhPAeNytELCmefpl/v/DU60ER34YSM 5XM2BVnXXcUZmOH4FN5xjfU8GIZ4+LPZ+BTuYQTUib9b7nh1okd2I4hBp27cAKEvjcwK i0CgO1o3wKW4eVNZDwD0ELDbzeEGt+ZfiSaLGJEt6Qd7j5t/1pgI8592CUp4LN3fI6LT 2S0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780911762; x=1781516562; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K89RrwpcqLo8zDg2OvFefmB2AQCgF8PACyQq7p8WH+I=; b=AZ11uN30oixd46BSx1TWZJ1tCylg2puYL29ARqXLn99I31+1G1rHG/EG6Lgauhv0/6 /pKm82CQhajPCZT4itJRd/YMYGR8X1Ji+55Cl5BZ3i+AIVQDpyr4Fp6F0zuRp90vsPSt c1dNArZmBNzEzQHRI2X92o+7VjYhh+Im3WhUZ+wmJC2hiW4DDbdBmQIyO2jSbi1uW96o fWqmEgsnMchi80WnkE+J5n65CwhXNc38TizTaRuHVfN/hHqBIcuEVQNFBPGv2NNp3bXa J08X1iFux/Tj6ErHmICdAgbbpuCghyUDFzCzFaMmUxBbP/PcTo3kzLyGjekncGoJZ8Eg dlgg== X-Forwarded-Encrypted: i=1; AFNElJ/3WWOPtwUcU2rATGMj+Yo0elk0GsKcjZIqIail1YLhl+VOVkZ7GphzNBTtJqLySUL9J0eQa5ksyWufsAY=@vger.kernel.org X-Gm-Message-State: AOJu0YwMTvdBG/AKXDRmgcXmaCfg1dwns90KjGWJ9Hw5T6THjyJlLT+s wDMJKIqi3QgnOD2G2rfV0pIpxuFq8E7VJBYA/Vf9fqHq7p2sDqJClS0N X-Gm-Gg: Acq92OFkSlCEPSuQLhhGQU/aRCp0DFQczpECW/y6O+3mZdzxWz7wjDGyWpIqBHdOTVA UWjhhFuiahMqz5Xgn2PRz+cFZxPN2IQAACz2ZD1xhNI8Dn8/Z2DQ1dENiRO2wxqED3/MxA4V2MA QcVC+3kypix+Rmkz2soDU8Xp19ooCYrPVwxwioIXS+rkl0kGc8JyZGGaBgnmC2xBAozthpWS8cC w5dye0+ajhHprLyM7dPxdfFhu/UOr3j+6zH19VeRk81R/rTKKeiZkwLXGLN0io2411MSSFjj+rm MR2ABEMyJziOW+ZZOPhifDzqHXn2OltxUoRDIcO3MbGtg4+55XtojdJXuIASz0fzMPE9/DuhJxQ 7KsNM59A/x00sPWgPq82M6+a5EcKXJ2m7U4L9csAenX9E+HsdhTkvu41oRiHqekAHbLNk/nGb4o 9JWclh2X06dYi7rP9Xkx/UsOq8Isk6YSILcjazl2KBsqe6HmegfTBV38Bz7v5ZcRcrcIPxLWeO8 PKoVUj0DgMnGJ0= X-Received: by 2002:a05:6a00:a227:b0:842:5719:455c with SMTP id d2e1a72fcca58-842b106587dmr14714982b3a.25.1780911761597; Mon, 08 Jun 2026 02:42:41 -0700 (PDT) Received: from [192.168.0.100] (60-250-196-139.hinet-ip.hinet.net. [60.250.196.139]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84282372868sm19883930b3a.17.2026.06.08.02.42.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2026 02:42:41 -0700 (PDT) Message-ID: <684fde52-569c-4b38-904c-dbb05054634f@gmail.com> Date: Mon, 8 Jun 2026 17:42:33 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/5] dt-bindings: display: verisilicon,dc: generalize for single-output variants To: Icenowy Zheng , maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org Cc: ychuang3@nuvoton.com, schung@nuvoton.com, yclu4@nuvoton.com, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260608023237.305036-1-a0987203069@gmail.com> <20260608023237.305036-2-a0987203069@gmail.com> Content-Language: en-US From: Joey Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/8/2026 2:32 PM, Icenowy Zheng wrote: > 在 2026-06-08一的 10:32 +0800，Joey Lu写道： >> The existing schema hard-codes the five-clock/three-reset/dual-port >> topology of the DC8200 IP block, preventing reuse for single-output >> variants such as the Verisilicon DCUltraLite used in the Nuvoton >> MA35D1 >> SoC. >> >> Rework the schema so that variant-specific constraints are expressed >> via >> allOf/if blocks: >> >> - Add nuvoton,ma35d1-dcu to the SoC-specific compatible enum.  The >>   generic verisilicon,dc fallback remains the driver-binding string. >> - Relax the top-level clocks/resets definitions to minItems ranges so >>   the base schema accepts both variants. >> - Keep ports in the global required list and keep >> additionalProperties >>   tightened to unevaluatedProperties. >> - Add an allOf/if block for thead,th1520-dc8200: five-clock (core, >> axi, >>   ahb, pix0, pix1), three-reset (core, axi, ahb). >> - Add an allOf/if block for nuvoton,ma35d1-dcu: two-clock (core, >> pix0), >>   one-reset (core). >> - Fix a stray space in the port@0 description. >> - Add a DT example for the Nuvoton MA35D1 DCU Lite using >> ports/port@0. >> >> Signed-off-by: Joey Lu >> --- >>  .../bindings/display/verisilicon,dc.yaml      | 103 +++++++++++++++- >> -- >>  1 file changed, 90 insertions(+), 13 deletions(-) >> >> diff --git >> a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml >> b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml >> index 9dc35ab973f2..db0260d874c5 100644 >> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml >> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml >> @@ -17,7 +17,8 @@ properties: >>      items: >>        - enum: >>            - thead,th1520-dc8200 >> -      - const: verisilicon,dc # DC IPs have discoverable ID/revision >> registers >> +          - nuvoton,ma35d1-dcu >> +      - const: verisilicon,dc  # DC IPs have discoverable >> ID/revision registers > Ah is an extra space added here, which leads to this hunk looking > strange? The extra space was added because `yamllint` reports "too few spaces before comment" (warning: comments) when only one space precedes the `#`. However, since this constitutes an unrelated whitespace change that makes the diff harder to read, I will revert to the original single-space form to keep the patch clean. >> >>    reg: >>      maxItems: 1 >> @@ -26,6 +27,7 @@ properties: >>      maxItems: 1 >> >>    clocks: >> +    minItems: 2 > Maybe restrictions about the clock count shouldn't be inserted here, > and technically it's possible that only the pixel clock is controllable > by Linux (all other clocks are in a fixed configuration). Understood. I will remove the per-variant clock items descriptions from the top-level `clocks:` section and move them into the respective allOf/if blocks. The top-level will only carry `minItems`/`maxItems` for schema validation range. >>      items: >>        - description: DC Core clock >>        - description: DMA AXI bus clock >> @@ -34,24 +36,19 @@ properties: >>        - description: Pixel clock of output 1 >> >>    clock-names: >> -    items: >> -      - const: core >> -      - const: axi >> -      - const: ahb >> -      - const: pix0 >> -      - const: pix1 > Ah I think the total list should still appear here, and they should be > corresponding to the descriptions above? Understood. I will restore the full items list for `clock-names` at the top level (all five entries: core, axi, ahb, pix0, pix1) and add `minItems` to make it flexible. Per-variant allOf blocks will only constrain with `minItems`/`maxItems`. >> +    minItems: 2 >> +    maxItems: 5 >> >>    resets: >> +    minItems: 1 >>      items: >>        - description: DC Core reset >>        - description: DMA AXI bus reset >>        - description: Configuration AHB bus reset >> >>    reset-names: >> -    items: >> -      - const: core >> -      - const: axi >> -      - const: ahb > Ditto here. Understood. I will restore the full items list for `reset-names` at the top level (core, axi, ahb) with `minItems`. Same pattern as clock-names. >> +    minItems: 1 >> +    maxItems: 3 >> >>    ports: >>      $ref: /schemas/graph.yaml#/properties/ports >> @@ -59,7 +56,7 @@ properties: >>      properties: >>        port@0: >>          $ref: /schemas/graph.yaml#/properties/port >> -        description: The first output channel , endpoint 0 should be >> +        description: The first output channel, endpoint 0 should be >>            used for DPI format output and endpoint 1 should be used >>            for DP format output. >> >> @@ -77,7 +74,60 @@ required: >>    - clock-names >>    - ports >> >> -additionalProperties: false >> +allOf: >> +  - if: >> +      properties: >> +        compatible: >> +          contains: >> +            const: thead,th1520-dc8200 >> +    then: >> +      properties: >> +        clocks: >> +          minItems: 5 >> +          maxItems: 5 >> + >> +        clock-names: >> +          items: >> +            - const: core >> +            - const: axi >> +            - const: ahb >> +            - const: pix0 >> +            - const: pix1 >> + >> +        resets: >> +          minItems: 3 >> +          maxItems: 3 >> + >> +        reset-names: >> +          items: >> +            - const: core >> +            - const: axi >> +            - const: ahb >> + >> +  - if: >> +      properties: >> +        compatible: >> +          contains: >> +            const: nuvoton,ma35d1-dcu >> +    then: >> +      properties: >> +        clocks: >> +          minItems: 2 >> +          maxItems: 2 >> + >> +        clock-names: >> +          items: >> +            - const: core >> +            - const: pix0 >> + >> +        resets: > Do we have minItems: 1 here? (The DT schema validator always has some > quirks that I fail to remember, so I am not sure.) Yes, I will add `minItems: 1` to `resets:` in the nuvoton block. >> +          maxItems: 1 >> + >> +        reset-names: >> +          items: >> +            - const: core >> + > I think resets should be described as required in both device-specific > bindings. > > Thanks, > Icenowy Understood. I will add `required: [resets, reset-names]` inside the `then:` block for both thead,th1520-dc8200 and nuvoton,ma35d1-dcu. Many thanks! >> +unevaluatedProperties: false >> >>  examples: >>    - | >> @@ -120,3 +170,30 @@ examples: >>          }; >>        }; >>      }; >> + >> +  - | >> +    #include >> +    #include >> +    #include >> + >> +    display@40260000 { >> +        compatible = "nuvoton,ma35d1-dcu", "verisilicon,dc"; >> +        reg = <0x40260000 0x20000>; >> +        interrupts = ; >> +        clocks = <&clk DCU_GATE>, <&clk DCUP_DIV>; >> +        clock-names = "core", "pix0"; >> +        resets = <&sys MA35D1_RESET_DISP>; >> +        reset-names = "core"; >> + >> +        ports { >> +            #address-cells = <1>; >> +            #size-cells = <0>; >> + >> +            port@0 { >> +                reg = <0>; >> +                dpi_out: endpoint { >> +                    remote-endpoint = <&panel_in>; >> +                }; >> +            }; >> +        }; >> +    };