linux-kernel - Re: [PATCH 01/12] dt-bindings: display: sprd: adapt for UMS9230 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250722-imported-origami-cat-dbfaad@kuoka>
Date: Tue, 22 Jul 2025 09:19:33 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Otto Pflüger <otto.pflueger@...cue.de>
Cc: David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Orson Zhai <orsonzhai@...il.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>, 
	Chunyan Zhang <zhang.lyra@...il.com>, Kevin Tang <kevin.tang@...soc.com>, 
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/12] dt-bindings: display: sprd: adapt for UMS9230
 support

On Sun, Jul 20, 2025 at 07:35:24PM +0200, Otto Pflüger wrote:
> On Sun, Jul 20, 2025 at 05:38:02PM +0200, Krzysztof Kozlowski wrote:
> > > 
> > > The clocks should be the same on sharkl3 (sc9863a) and ums9230, but
> > > the existing bindings don't really make sense here or are incomplete.
> > > AFAIK there is no SoC in which this display controller is directly
> > > connected to the PLL as shown in the example. The DSI controller is
> > 
> > This is not the PLL. Gate either. You are looking from wrong side - how
> > clock is generated.
> > 
> > You describe here CLOCK INPUT.
> > 
> > > connected to a clock gate. The DPU actually does have two clocks, both
> > > of which are clock muxes that allow selecting different frequencies and
> > > one of which is behind a clock gate. I can add the second clock for the
> > > DPU if needed.
> > > 
> > > Since nothing seems to be using these bindings at the moment, would it
> > > be okay to drop the old clock names that refer to specific frequencies?
> > 
> > It is still completely irrelevant whether these are muxes. Dropping
> > existing properties is ABI change, but anyway first figure out what is
> > here really.
> 
> I was trying to point out that the existing clock names are incorrect
> because they refer to a specific source that is not necessarily used
> for these clocks, instead of giving a name for the clock input.

OK, if the old name refers to the same clock input as in your new
device, you can deprecate old case in the binding.

> 
> For the DPU, would "core" and "dpi" be more appropriate as clock names?
> DPI refers to the interface used internally between the DPU and the DSI
> controller.

Sounds fine.

> 
> For the DSI controller, it seems that the clock is actually an APB bus
> clock needed for accessing the control registers. Again, it is not
> required to be connected to a 96MHz clock source as the name used in the
> binding suggests. Would something like "apb_clk" or "pclk" be more
> descriptive?

Yeah, both are correct. I think pclk is preferred.

Best regards,
Krzysztof