* Re: [PATCH v4 9/9] clk: sunxi-ng: sun6i-rtc: add a733 support
From: sashiko-bot @ 2026-07-06 10:26 UTC (permalink / raw)
To: Jerome Brunet
Cc: robh, conor+dt, devicetree, linux-rtc, Alexandre Belloni,
linux-sunxi
In-Reply-To: <20260706-a733-rtc-v4-9-f330728db3d3@baylibre.com>
> Add support for the sun60i a733 CCU RTC.
>
> Compared to the a523, this SoC has a different input oscillator divider
> which auto-detects the oscillator rate and select a divider to provide
> a fixed 32768Hz clock. It also provides several phy reference clocks
> with dedicated clock gates.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706-a733-rtc-v4-0-f330728db3d3@baylibre.com?part=9
^ permalink raw reply
* Re: [PATCH v4 6/9] clk: sunxi-ng: div: add read-only operation support
From: Jerome Brunet @ 2026-07-06 12:36 UTC (permalink / raw)
To: sashiko-bot
Cc: sashiko-reviews, conor+dt, robh, linux-rtc, Alexandre Belloni,
devicetree, linux-sunxi
In-Reply-To: <20260706100635.E5DC61F000E9@smtp.kernel.org>
On lun. 06 juil. 2026 at 10:06, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Inconsistent rate calculation between `determine_rate` and `recalc_rate` due to division order.
> --
>
> commit 39f872462c04ad724c3624b152234160de56a47e
> Author: Jerome Brunet <jbrunet@baylibre.com>
>
> clk: sunxi-ng: div: add read-only operation support
>
> Add support for sunxi-ng read-only dividers. This will be
> useful to the a733 oscillator detection logic.
>
>> diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
>> index 62d680ccb524b..d1c8c7baa12dc 100644
>> --- a/drivers/clk/sunxi-ng/ccu_div.c
>> +++ b/drivers/clk/sunxi-ng/ccu_div.c
> [ ... ]
>> @@ -84,6 +84,36 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
>> req, ccu_div_determine_rate_helper, cd);
>> }
>>
>> +static int ccu_rodiv_determine_rate(struct clk_hw *hw,
>> + struct clk_rate_request *req)
>> +{
>> + struct ccu_div *cd = hw_to_ccu_div(hw);
>> + unsigned long val;
>> + u32 reg;
>> + int ret;
>> +
>> + reg = readl(cd->common.base + cd->common.reg);
>> + val = reg >> cd->div.shift;
>> + val &= (1 << cd->div.width) - 1;
>> +
>> + req->rate = ccu_mux_helper_unapply_prediv(&cd->common, &cd->mux, -1,
>> + req->rate);
>> +
>> + if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
>> + req->rate *= cd->fixed_post_div;
>> +
>> + ret = divider_ro_determine_rate(hw, req, cd->div.table,
>> + cd->div.width, cd->div.flags, val);
>> +
>> + if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
>> + req->rate /= cd->fixed_post_div;
>> +
>> + req->rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
>> + req->rate);
>
> [Severity: Medium]
> Will this division order cause inconsistent rate calculations compared to
> ccu_div_recalc_rate()?
>
> The divider_ro_determine_rate() helper applies DIV_ROUND_UP() to the unadjusted
> parent rate, and then this function divides that result by fixed_post_div and
> prediv.
>
> However, ccu_div_recalc_rate() applies prediv to the parent rate first, then
> calculates the divider rate, and finally divides by fixed_post_div.
>
> Since the Common Clock Framework requires determine_rate and recalc_rate to be
> mathematically consistent, could this discrepancy cause rate mismatches or
> warnings for clocks using a pre-divider or fixed post-divider?
I think the RO side is correct and RW one is not.
The RO part correctly walk back the tree by un-applying the predivider
so, whatever CCF does with the parent rate value will be correct.
The RW part query the parent rate then applies the prediv. This
will be thrown away when/if clk_divider_bestdiv() calls
clk_hw_round_rate() on the parent. If that happens, the subsequent
un-apply of the prediv would make the matter even worse. So (if I
understand all this correctly) this case does not happen yet, otherwise
we would have noticed, and it can be fixed separately.
Side Note: I've not followed the sunxi history behind all those
prediv/postdiv but I find them a bit confusing. It seems like inserting
some fixed factor clocks in the clock trees would accomplish the same
thing while simplifying mux/divider quite a lot by droping these quirks ?
Side Note #2: I feel that while sashiko is pointing out valid things but we
are slowly getting off topic and down the rabbit hole with it ...
>
>> +
>> + return ret;
>> +}
>> +
--
Jerome
^ permalink raw reply
* Re: [PATCH v4 6/9] clk: sunxi-ng: div: add read-only operation support
From: Chen-Yu Tsai @ 2026-07-06 13:09 UTC (permalink / raw)
To: Jerome Brunet
Cc: sashiko-bot, sashiko-reviews, conor+dt, robh, linux-rtc,
Alexandre Belloni, devicetree, linux-sunxi
In-Reply-To: <1jv7asguqu.fsf@starbuckisacylon.baylibre.com>
On Mon, Jul 6, 2026 at 8:36 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On lun. 06 juil. 2026 at 10:06, sashiko-bot@kernel.org wrote:
>
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] Inconsistent rate calculation between `determine_rate` and `recalc_rate` due to division order.
> > --
> >
> > commit 39f872462c04ad724c3624b152234160de56a47e
> > Author: Jerome Brunet <jbrunet@baylibre.com>
> >
> > clk: sunxi-ng: div: add read-only operation support
> >
> > Add support for sunxi-ng read-only dividers. This will be
> > useful to the a733 oscillator detection logic.
> >
> >> diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
> >> index 62d680ccb524b..d1c8c7baa12dc 100644
> >> --- a/drivers/clk/sunxi-ng/ccu_div.c
> >> +++ b/drivers/clk/sunxi-ng/ccu_div.c
> > [ ... ]
> >> @@ -84,6 +84,36 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
> >> req, ccu_div_determine_rate_helper, cd);
> >> }
> >>
> >> +static int ccu_rodiv_determine_rate(struct clk_hw *hw,
> >> + struct clk_rate_request *req)
> >> +{
> >> + struct ccu_div *cd = hw_to_ccu_div(hw);
> >> + unsigned long val;
> >> + u32 reg;
> >> + int ret;
> >> +
> >> + reg = readl(cd->common.base + cd->common.reg);
> >> + val = reg >> cd->div.shift;
> >> + val &= (1 << cd->div.width) - 1;
> >> +
> >> + req->rate = ccu_mux_helper_unapply_prediv(&cd->common, &cd->mux, -1,
> >> + req->rate);
> >> +
> >> + if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
> >> + req->rate *= cd->fixed_post_div;
> >> +
> >> + ret = divider_ro_determine_rate(hw, req, cd->div.table,
> >> + cd->div.width, cd->div.flags, val);
> >> +
> >> + if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
> >> + req->rate /= cd->fixed_post_div;
> >> +
> >> + req->rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
> >> + req->rate);
> >
> > [Severity: Medium]
> > Will this division order cause inconsistent rate calculations compared to
> > ccu_div_recalc_rate()?
> >
> > The divider_ro_determine_rate() helper applies DIV_ROUND_UP() to the unadjusted
> > parent rate, and then this function divides that result by fixed_post_div and
> > prediv.
> >
> > However, ccu_div_recalc_rate() applies prediv to the parent rate first, then
> > calculates the divider rate, and finally divides by fixed_post_div.
> >
> > Since the Common Clock Framework requires determine_rate and recalc_rate to be
> > mathematically consistent, could this discrepancy cause rate mismatches or
> > warnings for clocks using a pre-divider or fixed post-divider?
>
> I think the RO side is correct and RW one is not.
>
> The RO part correctly walk back the tree by un-applying the predivider
> so, whatever CCF does with the parent rate value will be correct.
>
> The RW part query the parent rate then applies the prediv. This
> will be thrown away when/if clk_divider_bestdiv() calls
> clk_hw_round_rate() on the parent. If that happens, the subsequent
> un-apply of the prediv would make the matter even worse. So (if I
> understand all this correctly) this case does not happen yet, otherwise
> we would have noticed, and it can be fixed separately.
Looking at the history, ccu_div_determine_rate_helper() used to be
ccu_div_round_rate(), so it wouldn't have tried all the parents. Looks
like I missed this when looking at the conversion patches back in
January.
The fix is easy though: just reimplement divider_round_rate_parent().
Somehow we did this already for the multiplier but not the divider.
BTW, would it make sense to implement ccu_rodiv_determine_rate() using
ccu_mux_helper_determine_rate() as well? That would make both RW and RW
consistent, but it would mean another rewrite for you ...
> Side Note: I've not followed the sunxi history behind all those
> prediv/postdiv but I find them a bit confusing. It seems like inserting
> some fixed factor clocks in the clock trees would accomplish the same
> thing while simplifying mux/divider quite a lot by droping these quirks ?
I think the whole idea was that we didn't want all those extra intermediate
clocks. If you look at drivers/clk/sunxi/ you can see that we came from a
one device node per clock design, which was messy and bloated. The second
try ended up being the "one clock per useful hardware clock unit" design
you see now..
And we somehow tied the list of clks to the exported list of clks,
which probably made it worse for adding intermediates.
> Side Note #2: I feel that while sashiko is pointing out valid things but we
> are slowly getting off topic and down the rabbit hole with it ...
Yeah. That's the downside of Sashiko.
Thanks
ChenYu
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox