Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Joey Lu <a0987203069@gmail.com>
To: Icenowy Zheng <zhengxingda@iscas.ac.cn>,
	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
Subject: Re: [PATCH v3 1/5] dt-bindings: display: verisilicon,dc: generalize for single-output variants
Date: Mon, 8 Jun 2026 17:42:33 +0800	[thread overview]
Message-ID: <684fde52-569c-4b38-904c-dbb05054634f@gmail.com> (raw)
In-Reply-To: <a3f6fa4529bff5390dd1beb164d600208dc650a5.camel@iscas.ac.cn>


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 <a0987203069@gmail.com>
>> ---
>>   .../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 <dt-bindings/interrupt-controller/arm-gic.h>
>> +    #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>> +    #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
>> +
>> +    display@40260000 {
>> +        compatible = "nuvoton,ma35d1-dcu", "verisilicon,dc";
>> +        reg = <0x40260000 0x20000>;
>> +        interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
>> +        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>;
>> +                };
>> +            };
>> +        };
>> +    };


  reply	other threads:[~2026-06-08  9:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08  2:32 [PATCH v3 0/5] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support Joey Lu
2026-06-08  2:32 ` [PATCH v3 1/5] dt-bindings: display: verisilicon,dc: generalize for single-output variants Joey Lu
2026-06-08  6:32   ` Icenowy Zheng
2026-06-08  9:42     ` Joey Lu [this message]
2026-06-08  8:00   ` Krzysztof Kozlowski
2026-06-08  9:44     ` Joey Lu
2026-06-08  8:02   ` Krzysztof Kozlowski
2026-06-08  9:44     ` Joey Lu
2026-06-08  2:32 ` [PATCH v3 2/5] drm/verisilicon: add register-level macros for DCU Lite Joey Lu
2026-06-08  2:32 ` [PATCH v3 3/5] drm/verisilicon: introduce per-variant hardware ops table Joey Lu
2026-06-08  6:24   ` Icenowy Zheng
2026-06-08  9:45     ` Joey Lu
2026-06-08 10:06       ` Icenowy Zheng
2026-06-08 10:35         ` Joey Lu
2026-06-08  2:32 ` [PATCH v3 4/5] drm/verisilicon: add Nuvoton MA35D1 DCU Lite display controller support Joey Lu
2026-06-08  6:26   ` Icenowy Zheng
2026-06-08  9:46     ` Joey Lu
2026-06-08  2:32 ` [PATCH v3 5/5] drm/verisilicon: add DCUltraLite chip identity to HWDB Joey Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=684fde52-569c-4b38-904c-dbb05054634f@gmail.com \
    --to=a0987203069@gmail.com \
    --cc=airlied@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh@kernel.org \
    --cc=schung@nuvoton.com \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=ychuang3@nuvoton.com \
    --cc=yclu4@nuvoton.com \
    --cc=zhengxingda@iscas.ac.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox