Re: [PATCH v3 1/3] dt-bindings: clk: tenstorrent: Add tenstorrent,atlantis-prcm

Hi Conor,

On Wed, Jan 28, 2026 at 11:32 AM Conor Dooley [off-list ref] wrote:

On Wed, Jan 28, 2026 at 09:42:42AM -0600, Anirudh Srinivasan wrote:

quoted

Hi Conor,

On Wed, Jan 28, 2026 at 9:02 AM Conor Dooley [off-list ref] wrote:

quoted

On Tue, Jan 27, 2026 at 05:39:33PM -0600, Anirudh Srinivasan wrote:

quoted

Hi Conor,

On Tue, Jan 27, 2026 at 1:58 PM Conor Dooley [off-list ref] wrote:

quoted

On Mon, Jan 26, 2026 at 03:07:14PM -0600, Anirudh Srinivasan wrote:

quoted

Document bindings for Tenstorrent Atlantis PRCM that manages clocks
and resets. This block is instantiated 4 times in the SoC.
This commit documents the clocks from the RCPU PRCM block.

Signed-off-by: Anirudh Srinivasan <redacted>
---

This is pretty suspect sounding, if the PLLs for !rcpu are controlled in
the rcpu register region, why is it not a clock parent for the !rcpu
prcms?

Right. Looking at the mail from Krzysztof, I suspect he meant to
completely document and explain the rcpu prcm, not all of the prcms (he
couldn't really know they existed, based on your v1, right?).
I'd suggest you drop the !rcpu stuff for now, and submit it when you
have the driver for them ready to go. That's typically what's done to
avoid introducing bindings that need to be changed once the driver
actually turns up, since as you say you've not actually tested the
driver for those prcms.

Okay, thank you for clarifying that. I think I interpreted the
original comments as "once you add bindings, you cannot change them
later". I guess the changes I have wouldn't break backward
compatibility, so they'd probably be fine. I will do this the way you
suggest.

If you think it is going to be confusing, then move the bits common to
!rcpu and rcpu prcms to a file, with the unique bits in dedicated files
perhaps? It seems like they'd be fairly different even with your current
scheme and keeping them apart would aid readability of the driver in
either case?
You can do this extraction as part of adding the !rcpu code, that
doesn't need to be done for the rcpu stuff since the concept of "common"
wouldn't exist in upstream until the !rcpu stuff arrives.

Okay, something to figure out for when I add the !rcpu code later.

Cheers,
Conor.