[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b9af5eec-db85-4465-895f-d7781ebe9dd9@riscstar.com>
Date: Mon, 24 Mar 2025 07:52:47 -0500
From: Alex Elder <elder@...cstar.com>
To: Haylen Chu <heylenay@....org>, p.zabel@...gutronix.de,
mturquette@...libre.com, sboyd@...nel.org, dlan@...too.org
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.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 RESEND 3/7] clk: spacemit: add reset controller support
On 3/24/25 7:20 AM, Haylen Chu wrote:
> 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@...cstar.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().
That's a great point, thank you. I'll modify it to use
regmap_update_bits(), which is better anyway.
-Alex
>
> Thanks,
> Haylen Chu
Powered by blists - more mailing lists