From: Haylen Chu <heylenay@4d2.org>
To: Alex Elder <elder@riscstar.com>,
p.zabel@pengutronix.de, mturquette@baylibre.com,
sboyd@kernel.org, dlan@gentoo.org
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
guodong@riscstar.com, 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 3/7] clk: spacemit: add reset controller support
Date: Mon, 24 Mar 2025 12:20:52 +0000 [thread overview]
Message-ID: <Z-FOJFHOsU_dLkmS@ketchup> (raw)
In-Reply-To: <20250321151831.623575-4-elder@riscstar.com>
On Fri, Mar 21, 2025 at 10:18:26AM -0500, Alex Elder wrote:
> Define ccu_reset_data as a structure that contains the constant
> register offset and bitmasks used to assert and deassert a reset
> control on a SpacemiT K1 CCU. Define ccu_reset_controller_data as
> a structure that contains the address of an array of those structures
> and a count of the number of elements in the array.
>
> Add a pointer to a ccu_reset_controller_data structure to the
> k1_ccu_data structure. Reset support is optional for SpacemiT CCUs;
> the new pointer field will be null for CCUs without any resets.
>
> Finally, define a new ccu_reset_controller structure, which (for
> a CCU with resets) contains a pointer to the constant reset data,
> the regmap to be used for the controller, and an embedded a reset
> controller structure.
>
> Each reset control is asserted or deasserted by updating bits in
> a register. The bits used are defined by an assert mask and a
> deassert mask. In some cases, one (non-zero) mask asserts reset
> and a different (non-zero) mask deasserts it. Otherwise one mask
> is nonzero, and the other is zero. Either way, the bits in
> both masks are cleared, then either the assert mask or the deassert
> mask is set in a register to affect the state of a reset control.
>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
> drivers/clk/spacemit/ccu-k1.c | 93 +++++++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/drivers/clk/spacemit/ccu-k1.c b/drivers/clk/spacemit/ccu-k1.c
> index f7367271396a0..6d879411c6c05 100644
> --- a/drivers/clk/spacemit/ccu-k1.c
> +++ b/drivers/clk/spacemit/ccu-k1.c
...
> +static int
> +k1_rst_update(struct reset_controller_dev *rcdev, unsigned long id, bool assert)
> +{
> + struct ccu_reset_controller *controller = rcdev_to_controller(rcdev);
> + struct regmap *regmap = controller->regmap;
> + const struct ccu_reset_data *data;
> + u32 val;
> + int ret;
> +
> + data = &controller->data->data[id];
> +
> + ret = regmap_read(regmap, data->offset, &val);
> + if (ret)
> + return ret;
> +
> + val &= ~(data->assert_mask | data->deassert_mask);
> + val |= assert ? data->assert_mask : data->deassert_mask;
> +
> + return regmap_write(regmap, data->offset, val);
> +}
I don't think it's safe to write the regmap based on a value read
earlier without the regmap's inner lock held: it's totally fine for the
clock part to issue an update of the register at the same time. Without
knowledge on it, reset code may rollback the clock bits written by clock
code earlier to the original value. That's why I keep using ccu_update()
everywhere and dropped ccu_write().
Thanks,
Haylen Chu
next prev parent reply other threads:[~2025-03-24 12: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 [this message]
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
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=Z-FOJFHOsU_dLkmS@ketchup \
--to=heylenay@4d2.org \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlan@gentoo.org \
--cc=elder@riscstar.com \
--cc=guodong@riscstar.com \
--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