All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: "Stefan Dösinger" <stefandoesinger@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings.
Date: Tue, 12 May 2026 18:02:03 +0100	[thread overview]
Message-ID: <20260512-musket-gaffe-376f0450a610@spud> (raw)
In-Reply-To: <DD71E384-1777-47B8-93C8-D6EFDA4BA74C@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On Tue, May 12, 2026 at 12:33:42AM +0300, Stefan Dösinger wrote:
> Hi Conor,
> 
> Thanks for your reply!
> 
> > Am 11.05.2026 um 19:07 schrieb Conor Dooley <conor@kernel.org>:
> > 
> > How come the "matrixclk" has no constraints on clock properties?
> 
> Because I am not sure what the correct/preferred way to express the interface between top and matrix is - see the first question raised in my cover letter.
> 
> In short, matrix potentially consumes all clocks available on the top controller. There is no obvious interface between them, like there is between matrix and LSP. So I see two ways to handle this in the bindings:
> 
> 1) List the top clk inputs, top clk PLL outputs and PLL fractionals as matrix input
> 2) Be quiet about it

Unless you want to model top + matrix as a single node with two register
regions, then list it all. Hiding the relationships is ill-advised IMO.

> 
> It'd be about 20 clocks or so that I know are consumed. The bigger issue than the number of clocks is that my knowledge of the board is from reverse engineering, not proper datasheets, so I might find out that a clock is missing or wrong.
> 
> > Although, these two devices seem too different to be in the same
> > dt-binding. Do they have anyhting in common other than the SoC they are
> > part of?
> 
> No, they don't have anything in common, other than that their concerns are poorly separated in hardware.
> 
> I take it from your question that the preferred way is to have separate bindings for them in this case - I guess separate headers as well as separate yaml files. Is this correct?

Separate headers if you like, separate bindings since the hardware and
binding are completely different between devices.

> The third clock controller - LSP - is nicely separated from the other two. I would not be surprised to see this subsystem of the board show up on a different ZTE board. If top and matrix should have different bindings, LSP certainly should as well.

The "two" I was referring to were the two with constraints, so top and
lsp, so that should answer that!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2026-05-12 17:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-10 21:49 [PATCH RFC v2 0/4] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-05-10 21:49 ` [PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings Stefan Dösinger
2026-05-11 16:07   ` Conor Dooley
2026-05-11 21:33     ` Stefan Dösinger
2026-05-12 17:02       ` Conor Dooley [this message]
2026-05-14 20:54         ` Stefan Dösinger
2026-05-11 22:12   ` sashiko-bot
2026-05-10 21:49 ` [PATCH RFC v2 2/4] clk: zte: Introduce a driver for zx297520v3 top clocks and resets Stefan Dösinger
2026-05-11 22:41   ` sashiko-bot
2026-05-10 21:49 ` [PATCH RFC v2 3/4] clk: zte: Introduce a driver for zx297520v3 matrix " Stefan Dösinger
2026-05-11 23:04   ` sashiko-bot
2026-05-10 21:49 ` [PATCH RFC v2 4/4] clk: zte: Introduce a driver for zx297520v3 LSP " Stefan Dösinger
2026-05-11 23:21   ` sashiko-bot

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=20260512-musket-gaffe-376f0450a610@spud \
    --to=conor@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=stefandoesinger@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.