From: Yixun Lan <dlan@gentoo.org>
To: Alex Elder <elder@riscstar.com>
Cc: p.zabel@pengutronix.de, mturquette@baylibre.com,
sboyd@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, heylenay@4d2.org, paul.walmsley@sifive.com,
palmer@dabbelt.com, aou@eecs.berkeley.edu,
spacemit@lists.linux.dev, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND 6/7] clk: spacemit: define new syscons with only resets
Date: Mon, 24 Mar 2025 06:21:29 +0000 [thread overview]
Message-ID: <20250324062129-GYA19363@gentoo> (raw)
In-Reply-To: <c080eb55-943e-4564-8dcc-dd5f27b296a9@riscstar.com>
Hi Alex:
On 08:23 Sun 23 Mar , Alex Elder wrote:
> On 3/22/25 11:42 AM, Yixun Lan wrote:
> > Hi Alex:
> >
> > It occur to me it's a little odd to implemnt reset driver
> > for RCPU block, but after check with vendor the RCPU region can
> > be accessed both by ACPU and RCPU, then I'm fine with this.
>
> I implemented just the resets that were found in the downstream
> code.
>
> I first implemented a separate reset driver, very simple, which
> only implemented the resets. I had a separate DTS binding (like
> was done for the PLLs). I was ready to post it for review, then
> noticed that the registers used were shared with clocks. So I
> merged all of that separate code into the clock driver, as you
> see here.
>
ok
> > ACPU - RISC-V Main CPU, with mmu, running Linux
> > RCPU - real time CPU, without mmu, running RT-OS
>
> I didn't realize there was a separate CPU running its
> own OS. Is this managed as a remoteproc by the RISC-V AP?
> The reset signals, I hope, are only touched by the AP
> and not the real-time CPU. Can you provide any further
> information about this?
>
As far as I know, the RCPU region can be acccesed via AP and real-time CPU
from hardware perspective, there is no guarantee of isolation,
so maybe software should take care of this in case only one side can touch
for remoteproc, I haven't checked, and it's unrelated to this discussion
(doesn't change shared resource fact whether remoteproc supported or not)
> > On 10:18 Fri 21 Mar , Alex Elder wrote:
> >> Enable support for three additional syscon CCUs which support reset
> >> controls but no clocks: ARCPU, RCPU2, and APBC2.
> >>
> >> Signed-off-by: Alex Elder <elder@riscstar.com>
> >> ---
> >> drivers/clk/spacemit/ccu-k1.c | 106 ++++++++++++++++++++++++++++++++++
> >> 1 file changed, 106 insertions(+)
> >>
> >> diff --git a/drivers/clk/spacemit/ccu-k1.c b/drivers/clk/spacemit/ccu-k1.c
> >> index 17e321c25959a..bf5a3e2048619 100644
> >> --- a/drivers/clk/spacemit/ccu-k1.c
> >> +++ b/drivers/clk/spacemit/ccu-k1.c
> >> @@ -130,6 +130,37 @@
> >> #define APMU_EMAC0_CLK_RES_CTRL 0x3e4
> >> #define APMU_EMAC1_CLK_RES_CTRL 0x3ec
> >>
> >> +/* RCPU register offsets */
> >> +#define RCPU_SSP0_CLK_RST 0x0028
> >> +#define RCPU_I2C0_CLK_RST 0x0030
> >> +#define RCPU_UART1_CLK_RST 0x003c
> >> +#define RCPU_CAN_CLK_RST 0x0048
> >> +#define RCPU_IR_CLK_RST 0x004c
> >> +#define RCPU_UART0_CLK_RST 0x00d8
> >> +/* XXX Next one is part of the AUD_AUDCLOCK region @ 0xc0882000 */
> > this comment looks odd, XXX?
>
> Yeah, I meant to remove that before sending but I forgot.
>
> The downstream code treats this one register as being
> part of the RCPU memory region, and extends that region
> to be 0x2048 bytes to "fit" it.
>
> The hardware documentation actually defines a different
> "RCPU Audio Clock" memory region, and it might be more
> correct (though less convenient) to define that as a
> distinct region of memory.
>
> What do you think?
>
I'm not sure, but from DT perspective, is it an independent device?
if yes, then need to describe as a distinct region..
> -Alex
>
> >> +#define AUDIO_HDMI_CLK_CTRL 0x2044
> >> +
> >> +/* RCPU2 register offsets */
> >> +#define RCPU2_PWM0_CLK_RST 0x0000
> >> +#define RCPU2_PWM1_CLK_RST 0x0004
> >> +#define RCPU2_PWM2_CLK_RST 0x0008
> >> +#define RCPU2_PWM3_CLK_RST 0x000c
> >> +#define RCPU2_PWM4_CLK_RST 0x0010
> >> +#define RCPU2_PWM5_CLK_RST 0x0014
> >> +#define RCPU2_PWM6_CLK_RST 0x0018
> >> +#define RCPU2_PWM7_CLK_RST 0x001c
> >> +#define RCPU2_PWM8_CLK_RST 0x0020
> >> +#define RCPU2_PWM9_CLK_RST 0x0024
> >> +
> >> +/* APBC2 register offsets */
> >> +#define APBC2_UART1_CLK_RST 0x0000
> >> +#define APBC2_SSP2_CLK_RST 0x0004
> >> +#define APBC2_TWSI3_CLK_RST 0x0008
> >> +#define APBC2_RTC_CLK_RST 0x000c
> >> +#define APBC2_TIMERS0_CLK_RST 0x0010
> >> +#define APBC2_KPC_CLK_RST 0x0014
> >> +#define APBC2_GPIO_CLK_RST 0x001c
> >> +
> >> struct spacemit_ccu_clk {
> >> int id;
> >> struct clk_hw *hw;
> >> @@ -1781,6 +1812,69 @@ static const struct k1_ccu_data k1_ccu_apmu_data = {
> >> .rst_data = &apmu_reset_controller_data,
> >> };
> >>
> >> +static const struct ccu_reset_data rcpu_reset_data[] = {
> >> + [RST_RCPU_SSP0] = RST_DATA(RCPU_SSP0_CLK_RST, 0, BIT(0)),
> >> + [RST_RCPU_I2C0] = RST_DATA(RCPU_I2C0_CLK_RST, 0, BIT(0)),
> >> + [RST_RCPU_UART1] = RST_DATA(RCPU_UART1_CLK_RST, 0, BIT(0)),
> >> + [RST_RCPU_IR] = RST_DATA(RCPU_CAN_CLK_RST, 0, BIT(0)),
> >> + [RST_RCPU_CAN] = RST_DATA(RCPU_IR_CLK_RST, 0, BIT(0)),
> >> + [RST_RCPU_UART0] = RST_DATA(RCPU_UART0_CLK_RST, 0, BIT(0)),
> >> + [RST_RCPU_HDMI_AUDIO] = RST_DATA(AUDIO_HDMI_CLK_CTRL, 0, BIT(0)),
> >> +};
> >> +
> >> +static const struct ccu_reset_controller_data rcpu_reset_controller_data = {
> >> + .count = ARRAY_SIZE(rcpu_reset_data),
> >> + .data = rcpu_reset_data,
> >> +};
> >> +
> >> +static struct k1_ccu_data k1_ccu_rcpu_data = {
> >> + /* No clocks in the RCPU CCU */
> >> + .rst_data = &rcpu_reset_controller_data,
> >> +};
> >> +
> >> +static const struct ccu_reset_data rcpu2_reset_data[] = {
> >> + [RST_RCPU2_PWM0] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM1] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM2] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM3] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM4] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM5] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM6] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM7] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM8] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> + [RST_RCPU2_PWM9] = RST_DATA(RCPU2_PWM9_CLK_RST, BIT(2), BIT(0)),
> >> +};
> >> +
> >> +static const struct ccu_reset_controller_data rcpu2_reset_controller_data = {
> >> + .count = ARRAY_SIZE(rcpu2_reset_data),
> >> + .data = rcpu2_reset_data,
> >> +};
> >> +
> >> +static struct k1_ccu_data k1_ccu_rcpu2_data = {
> >> + /* No clocks in the RCPU2 CCU */
> >> + .rst_data = &rcpu2_reset_controller_data,
> >> +};
> >> +
> >> +static const struct ccu_reset_data apbc2_reset_data[] = {
> >> + [RST_APBC2_UART1] = RST_DATA(APBC2_UART1_CLK_RST, BIT(2), (0)),
> >> + [RST_APBC2_SSP2] = RST_DATA(APBC2_SSP2_CLK_RST, BIT(2), (0)),
> >> + [RST_APBC2_TWSI3] = RST_DATA(APBC2_TWSI3_CLK_RST, BIT(2), (0)),
> >> + [RST_APBC2_RTC] = RST_DATA(APBC2_RTC_CLK_RST, BIT(2), (0)),
> >> + [RST_APBC2_TIMERS0] = RST_DATA(APBC2_TIMERS0_CLK_RST, BIT(2), (0)),
> >> + [RST_APBC2_KPC] = RST_DATA(APBC2_KPC_CLK_RST, BIT(2), (0)),
> >> + [RST_APBC2_GPIO] = RST_DATA(APBC2_GPIO_CLK_RST, BIT(2), (0)),
> >> +};
> >> +
> >> +static const struct ccu_reset_controller_data apbc2_reset_controller_data = {
> >> + .count = ARRAY_SIZE(apbc2_reset_data),
> >> + .data = apbc2_reset_data,
> >> +};
> >> +
> >> +static struct k1_ccu_data k1_ccu_apbc2_data = {
> >> + /* No clocks in the RCPU2 CCU */
> >> + .rst_data = &apbc2_reset_controller_data,
> >> +};
> >> +
> >> static struct ccu_reset_controller *
> >> rcdev_to_controller(struct reset_controller_dev *rcdev)
> >> {
> >> @@ -1959,6 +2053,18 @@ static const struct of_device_id of_k1_ccu_match[] = {
> >> .compatible = "spacemit,k1-syscon-apmu",
> >> .data = &k1_ccu_apmu_data,
> >> },
> >> + {
> >> + .compatible = "spacemit,k1-syscon-rcpu",
> >> + .data = &k1_ccu_rcpu_data,
> >> + },
> >> + {
> >> + .compatible = "spacemit,k1-syscon-rcpu2",
> >> + .data = &k1_ccu_rcpu2_data,
> >> + },
> >> + {
> >> + .compatible = "spacemit,k1-syscon-apbc2",
> >> + .data = &k1_ccu_apbc2_data,
> >> + },
> >> { }
> >> };
> >> MODULE_DEVICE_TABLE(of, of_k1_ccu_match);
> >> --
> >> 2.43.0
> >>
> >
>
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
next prev parent reply other threads:[~2025-03-24 6:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 15:18 [PATCH RESEND 0/7] clk: spacemit: add K1 reset support Alex Elder
2025-03-21 15:18 ` [PATCH RESEND 1/7] dt-bindings: soc: spacemit: define spacemit,k1-ccu resets Alex Elder
2025-03-21 20:42 ` Rob Herring
2025-03-21 22:25 ` Yixun Lan
2025-03-22 14:27 ` Alex Elder
2025-03-22 16:51 ` Yixun Lan
2025-03-21 15:18 ` [PATCH RESEND 2/7] clk: spacemit: define struct k1_ccu_data Alex Elder
2025-03-22 15:50 ` Yixun Lan
2025-03-23 12:43 ` Alex Elder
2025-03-23 13:04 ` Yixun Lan
2025-03-23 22:30 ` Alex Elder
2025-03-28 17:24 ` Alex Elder
2025-03-24 11:53 ` Haylen Chu
2025-03-24 12:17 ` Alex Elder
2025-03-21 15:18 ` [PATCH RESEND 3/7] clk: spacemit: add reset controller support Alex Elder
2025-03-22 16:19 ` Yixun Lan
2025-03-23 13:23 ` Alex Elder
2025-03-24 6:40 ` Yixun Lan
2025-03-24 12:20 ` Haylen Chu
2025-03-24 12:52 ` Alex Elder
2025-03-21 15:18 ` [PATCH RESEND 4/7] clk: spacemit: define existing syscon resets Alex Elder
2025-03-22 16:29 ` Yixun Lan
2025-03-23 13:23 ` Alex Elder
2025-03-24 6:24 ` Yixun Lan
2025-03-21 15:18 ` [PATCH RESEND 5/7] clk: spacemit: make clocks optional Alex Elder
2025-03-21 15:18 ` [PATCH RESEND 6/7] clk: spacemit: define new syscons with only resets Alex Elder
2025-03-22 16:42 ` Yixun Lan
2025-03-23 13:23 ` Alex Elder
2025-03-24 6:21 ` Yixun Lan [this message]
2025-03-28 17:24 ` Alex Elder
2025-03-21 15:18 ` [PATCH RESEND 7/7] riscv: dts: spacemit: add reset support for the K1 SoC Alex Elder
2025-03-22 16:48 ` Yixun Lan
2025-03-23 13:23 ` Alex Elder
2025-03-24 6:06 ` Yixun Lan
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=20250324062129-GYA19363@gentoo \
--to=dlan@gentoo.org \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=elder@riscstar.com \
--cc=heylenay@4d2.org \
--cc=krzk+dt@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=p.zabel@pengutronix.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=spacemit@lists.linux.dev \
/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