[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dbd81c1b07f65edc77329ff479bdf9c790c78120.camel@pengutronix.de>
Date: Tue, 15 Apr 2025 10:24:39 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Alex Elder <elder@...cstar.com>, mturquette@...libre.com,
sboyd@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org
Cc: dlan@...too.org, heylenay@....org, guodong@...cstar.com,
paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
spacemit@...ts.linux.dev, devicetree@...r.kernel.org,
linux-clk@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 3/7] clk: spacemit: add reset controller support
On Mo, 2025-04-14 at 14:17 -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. Add a pointer to an array of those
> structures to the spacemit_ccu_data structure, along with a field
> indicating how many elements are in that array. Resets will be
> optional, and if none are defined the reset array pointer will be
> null.
>
> 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@...cstar.com>
Reviewed-by: Philipp Zabel <p.zabel@...gutronix.de>
regards
Philipp
Powered by blists - more mailing lists