Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Joey Lu <a0987203069@gmail.com>
To: Conor Dooley <conor@kernel.org>, Icenowy Zheng <zhengxingda@iscas.ac.cn>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	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,
	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 v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
Date: Tue, 30 Jun 2026 15:08:06 +0800	[thread overview]
Message-ID: <54fd4b86-d978-4f21-8634-292ecbe484ed@gmail.com> (raw)
In-Reply-To: <20260629-chevron-awhile-7cf456a768a0@spud>


On 6/29/2026 11:02 PM, Conor Dooley wrote:
> On Mon, Jun 29, 2026 at 01:31:46PM +0800, Icenowy Zheng wrote:
>>>>>>>>>> +
>>>>>>>>>> +        resets:
>>>>>>>>>> +          minItems: 1
>>>>>>>>>> +          maxItems: 1
>>>>>>>>>> +
>>>>>>>>>> +        reset-names:
>>>>>>>>>> +          items:
>>>>>>>>>> +            - const: core
>>>>>>>>> This is just maxItems: 1.
>>>>>>>> Well the implicit rules of DT binding schemas are quite
>>>>>>>> weird...
>>>>>>> I don't think it is that strange, as the binding has
>>>>>>>     reset-names:
>>>>>>>       items:
>>>>>>>         - const: core
>>>>>>>         - const: axi
>>>>>>>         - const: ahb
>>>>>> Ah does the list constraint the order of items? If it
>>>>>> constrains
>>>>>> the
>>>>> It does, yes.
>>>>> Alternatively, using an enum permits free ordering.
>>>> Ah in this case this should be converted to an enum, I think.
>>>>
>>>> Should I send a patch for converting it?
>>>>
>>>> Thanks,
>>>> Icenowy
>>> Thank you all for the detailed review and discussion, it really
>>> helped
>>> clarify the right approach.
>>>
>>> Since I will supply all four clocks with the same phandle for
>>> core/axi/ahb,
>>> and only one reset "core" for MA35D1, the ordering constraint in the
>>> `items` list is not a problem, "core" is already the first entry.
>>> There
>>> is no need to convert to an enum.
>>>
>>> Regarding the clock situation for the MA35D1: I agree with supplying
>>> all
>>> four clocks (core, axi, ahb, pix0) in the devicetree, even though the
>>> MA35D1 clock controller gates core/axi/ahb with a single bit. The DT
>>> will
>>> use the same clock phandle for core, axi, and ahb:
>>>
>>>     clocks = <&clk X>, <&clk X>, <&clk X>, <&pix_clk Y>;
>>>     clock-names = "core", "axi", "ahb", "pix0";
>>>
>>> This correctly models the hardware topology. Since all three names
>> No, this doesn't correctly model the hardware topology -- this will
>> lead to clk_get_rate() return the rate of DC core clock when checking
>> the AXI clock rate, which is problematic because both clocks are
>> limiting the performance of the DC.
You are right. The current MA35D1 clock driver does not correctly reflect
the real AXI/AHB clock rates, and I think it needs a more comprehensive
review and rework. I will address this in a separate clock driver patch
series in the future.

For this DRM patch series, the AXI and AHB clocks are shared system bus
clocks fixed by the SoC clock tree and are not managed by the display
driver. The driver does not query their frequencies for mode validation
or bandwidth decisions. Therefore, driver correctness is independent of
the reported AXI/AHB clock rates, meaning it will remain unaffected when
the clock driver is later reworked.
>>> resolve
>>> to the same underlying clock node, the CCF's standard enable
>>> refcounting
>>> handles the shared gate correctly without any custom implementation
>>> needed.
>>> I will also revert the change in patch 4/7 that made axi and ahb
>>> clocks
>>> optional, since they will now always be provided in the devicetree.
>>>
>>> Regarding moving `resets` and `reset-names` to the top-level
>>> `required:`,
>>> I will wait for Icenowy's patch to land before sending v6 to avoid
>>> duplicating the work.
>> The patch is sent.
Got it.
>>> In v6 I will update patch 1/7 with:
>>> - Update the subject to "dt-bindings: display: verisilicon,dc: add
>>>     support for nuvoton,ma35d1-dcu"
>>> - Lower `clocks`/`clock-names` `minItems` to 4 at the top level
>>> - Remove the `thead,th1520-dc8200` conditional block entirely
>> I think this conditional block will still be needed, because it will
>> need to constrain the minItems to ensure all clocks / resets are
>> populated.
> Correct. When the outer constraints are relaxed to deal with the new
> device the conditional block for the th1520 becomes required. Or having
> an else, but if all devices are likely to be different in terms of
> configuration specific conditional blocks is better.
Understood. I will keep the `thead,th1520-dc8200` conditional block.


  reply	other threads:[~2026-06-30  7:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-25  9:44 [PATCH v5 0/7] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support Joey Lu
2026-06-25  9:44 ` [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants Joey Lu
2026-06-25 16:33   ` Conor Dooley
2026-06-26  5:27     ` Icenowy Zheng
2026-06-26  7:19       ` Conor Dooley
2026-06-26  9:00         ` Icenowy Zheng
2026-06-26  9:26           ` Conor Dooley
2026-06-26  9:33             ` Icenowy Zheng
2026-06-26 15:32               ` Conor Dooley
2026-06-29  3:47               ` Joey Lu
2026-06-29  5:31                 ` Icenowy Zheng
2026-06-29 15:02                   ` Conor Dooley
2026-06-30  7:08                     ` Joey Lu [this message]
2026-06-26  7:22     ` Conor Dooley
2026-06-26  7:58       ` Icenowy Zheng
2026-06-26  8:57         ` Conor Dooley
2026-06-26  9:09           ` Icenowy Zheng
2026-06-26 15:16             ` Conor Dooley
2026-06-25  9:44 ` [PATCH v5 2/7] drm/verisilicon: add register-level macros for DC8000 Joey Lu
2026-06-25  9:44 ` [PATCH v5 3/7] drm/verisilicon: introduce per-variant hardware ops table Joey Lu
2026-06-26  8:02   ` Icenowy Zheng
2026-06-29  3:52     ` Joey Lu
2026-06-25  9:44 ` [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional Joey Lu
2026-06-26  8:03   ` Icenowy Zheng
2026-06-29  3:48     ` Joey Lu
2026-06-25  9:44 ` [PATCH v5 5/7] drm/verisilicon: add DC8000 (DCUltraLite) display controller support Joey Lu
2026-06-26  8:03   ` Icenowy Zheng
2026-06-29  3:54     ` Joey Lu
2026-06-25  9:44 ` [PATCH v5 6/7] drm/verisilicon: add DCUltraLite chip identity to HWDB Joey Lu
2026-06-26  8:04   ` Icenowy Zheng
2026-06-25  9:44 ` [PATCH v5 7/7] drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms Joey Lu
2026-06-26  8:05 ` [PATCH v5 0/7] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support Icenowy Zheng

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=54fd4b86-d978-4f21-8634-292ecbe484ed@gmail.com \
    --to=a0987203069@gmail.com \
    --cc=airlied@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=conor@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