From: Alex Elder <elder@riscstar.com>
To: Haylen Chu <heylenay@4d2.org>, Krzysztof Kozlowski <krzk@kernel.org>
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>,
Haylen Chu <heylenay@outlook.com>, Yixun Lan <dlan@gentoo.org>,
linux-riscv@lists.infradead.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Inochi Amaoto <inochiama@outlook.com>,
Chen Wang <unicornxdotw@foxmail.com>,
Jisheng Zhang <jszhang@kernel.org>,
Meng Zhang <zhangmeng.kevin@linux.spacemit.com>,
Guodong Xu <guodong@riscstar.com>
Subject: Re: [PATCH v4 2/4] dt-bindings: soc: spacemit: Add spacemit,k1-syscon
Date: Fri, 21 Feb 2025 17:40:56 -0600 [thread overview]
Message-ID: <7c697e9a-d6d9-4672-9738-93ce3a71beb6@riscstar.com> (raw)
In-Reply-To: <Z7BTVu10EKHMqOnJ@ketchup>
I have a general proposal on how to represent this, but I'd
like to know whether it makes sense. It might be what Krzysztof
is suggesting, but in any case, I hope this representation would
work, because it could simplify the code, and compartmentalizes
things.
Part of what motivates this is that I've been looking at the
downstream reset code this week. It contains a large number of
register offset definitions identical to what's used for the
clock driver. The reset driver uses exactly the same registers
as the clock driver does. Downstream they are separate drivers,
but the clock driver exports a shared spinlock for both drivers
to use.
These really need to be incorporated into the same driver for
upstream.
The clock code defines four distinct "units" (a term I'll use
from here on; there might be a better name):
MPMU Main Power Management Unit
APMU Application Power Management Unit
APBC APB Clock
APBS APB Spare
The reset code defines some of those, but doesn't use APBS.
It also defines three more:
APBC2 Another APB Clock
RCPU Real-time CPU?
RCPU2 Another Real-time CPU
Each of these "units" has a distinct I/O memory region that
contains registers that manage the clocks and reset signals.
I suggest a single "k1-clocks" device be created, which has
access to all of the I/O address ranges. And then within
the DT node for that device there is a sub-node for the
clocks, and another sub-node for the resets. Each of these
uses 2 cells for addressing. The first indicates which
"unit" contains the clock or reset registers, and the
second indicates the clock or reset line implemented by
that unit.
I might not have this exactly right, but below I show some
DTS code that I hope demonstrates what I mean.
Could this approach, or something close, work?
-Alex
/* SpacemiT clock/reset unit numbers */
#define SPACEMIT_CRST_RCPU 0
#define SPACEMIT_CRST_RCPU2 1
#define SPACEMIT_CRST_APBC 2
/* . . . */
#define SPACEMIT_CRST_APBC2 6
/* SpacemiT RCPU unit reset IDs */
#define SPACEMIT_RCPU_HDMIAUDIO 0
#define SPACEMIT_RCPU_CAN 1
/* . . . */
#define SPACEMIT_RCPU_UART1 6
/* SpacemiT RCPU2 unit reset IDs */
#define SPACEMIT_RCPU2_PWM0 0
#define SPACEMIT_RCPU2_PWM1 1
/* . . . */
#define SPACEMIT_RCPU2_PWM9 9
/* SpacemiT APBC unit reset/clock IDs */
#define SPACEMIT_APBC_UART1 0
#define SPACEMIT_APBC_UART2 1
#define SPACEMIT_APBC_GPIO 2
/* . . . */
#define SPACEMIT_APBC_TWSI0 27
/* APBC reset/clock IDs */
#define SPACEMIT_APBC_UART1 0
#define SPACEMIT_APBC_UART2 1
#define SPACEMIT_APBC_GPIO 2
/* . . . */
clocks {
compatible = "spacemit,k1-clocks";
reg = <0x0 0xc0880000 0x0 0x2050>,
<0x0 0xc0888000 0x0 0x30>,
<0x0 0xd4015000 0x0 0x1000>,
<0x0 0xd4050000 0x0 0x209c>,
<0x0 0xd4090000 0x0 0x1000>,
<0x0 0xd4282800 0x0 0x400>,
<0x0 0xf0610000 0x0 0x20>;
reg-names = "rcpu",
"rcpu2",
"apbc",
"mpmu",
"apbs",
"apmu",
"apbc2";
/*
* The two reset cells indicate:
* unit number (e.g. SPACEMIT_CRST_RCPU)
* reset within that unit (e.g. SPACEMIT_RCPU_CAN)
*/
k1_reset: spacemit-k1-reset {
#reset-cells = <2>;
};
/*
* The two clock cells indicate:
* unit number (e.g. SPACEMIT_CRST_APBC)
* clock within that unit (e.g. SPACEMIT_APBC_UART1)
*/
k1_clock: spacemit-k1-clock {
#clock-cells = <2>;
};
/* . . . */
};
/* . . . */
uart8: serial@d4017700 {
compatible = "spacemit,k1-uart",
"intel,xscale-uart";
reg = <0x0 0xd4017700 0x0 0x100>;
interrupts = <50>;
clocks = <&k1_clock SPACEMIT_CRST_APBC SPACEMIT_APBC_UART8>;
<&k1_clock SPACEMIT_CRST_APBC SPACEMIT_APBC_UART8_BUS>;
clock-names = "core",
"bus";
reg-shift = <2>;
reg-io-width = <4>;
resets = <&k1_reset SPACEMIT_CRST_APBC SPACEMIT_APBC_UART8>;
status = "disabled";
};
next prev parent reply other threads:[~2025-02-21 23:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 21:56 [PATCH v4 0/4] Add clock controller support for SpacemiT K1 Haylen Chu
2025-01-03 21:56 ` [PATCH v4 1/4] dt-bindings: clock: spacemit: Add clock controllers of Spacemit K1 SoC Haylen Chu
2025-01-04 9:58 ` Krzysztof Kozlowski
2025-01-15 7:29 ` Haylen Chu
2025-01-03 21:56 ` [PATCH v4 2/4] dt-bindings: soc: spacemit: Add spacemit,k1-syscon Haylen Chu
2025-01-04 10:07 ` Krzysztof Kozlowski
2025-02-11 5:15 ` Haylen Chu
2025-02-11 8:03 ` Krzysztof Kozlowski
2025-02-13 11:14 ` Haylen Chu
2025-02-13 18:07 ` Krzysztof Kozlowski
2025-02-15 8:41 ` Haylen Chu
2025-02-21 23:40 ` Alex Elder [this message]
2025-02-22 9:59 ` Krzysztof Kozlowski
2025-02-22 10:48 ` Haylen Chu
2025-02-22 11:50 ` Krzysztof Kozlowski
2025-02-24 10:17 ` Haylen Chu
2025-02-25 8:12 ` Krzysztof Kozlowski
2025-02-25 21:14 ` Alex Elder
2025-02-22 9:52 ` Krzysztof Kozlowski
2025-02-22 11:36 ` Haylen Chu
2025-01-03 21:56 ` [PATCH v4 3/4] clk: spacemit: Add clock support for Spacemit K1 SoC Haylen Chu
2025-01-16 5:25 ` Samuel Holland
2025-01-21 17:01 ` Haylen Chu
2025-02-14 4:04 ` Alex Elder
2025-02-16 11:34 ` Haylen Chu
2025-02-21 21:10 ` Alex Elder
2025-02-22 9:57 ` Haylen Chu
2025-02-22 9:40 ` Haylen Chu
2025-03-03 9:41 ` Haylen Chu
2025-03-03 14:10 ` Alex Elder
2025-01-03 21:56 ` [PATCH v4 4/4] riscv: dts: spacemit: Add clock controller for K1 Haylen Chu
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=7c697e9a-d6d9-4672-9738-93ce3a71beb6@riscstar.com \
--to=elder@riscstar.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlan@gentoo.org \
--cc=guodong@riscstar.com \
--cc=heylenay@4d2.org \
--cc=heylenay@outlook.com \
--cc=inochiama@outlook.com \
--cc=jszhang@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=unicornxdotw@foxmail.com \
--cc=zhangmeng.kevin@linux.spacemit.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®