All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Xilin Wu <sophon@radxa.com>,
	 Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	 Dzmitry Sankouski <dsankouski@gmail.com>,
	Taniya Das <quic_tdas@quicinc.com>,
	 Mike Turquette <mturquette@linaro.org>,
	linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
	 linux-kernel@vger.kernel.org,
	Stephen Boyd <sboyd@codeaurora.org>,
	 Mike Tipton <quic_mdtipton@quicinc.com>
Subject: Re: [PATCH 4/5] clk: qcom: clk-rcg2: calculate timeout based on clock frequency
Date: Wed, 8 Apr 2026 20:55:41 -0500	[thread overview]
Message-ID: <adcGdXeqltQVwPLz@baldur> (raw)
In-Reply-To: <c2cdc581-2f8f-4495-bb87-812b27a1e381@oss.qualcomm.com>

On Tue, Apr 07, 2026 at 12:13:09PM +0200, Konrad Dybcio wrote:
> On 4/6/26 5:54 PM, Xilin Wu wrote:
> > RCGs with extremely low rates (tens of Hz to low kHz) take much longer
> > to update than the fixed 500 us timeout allows. A 1 kHz clock needs at
> > least 3 ms (3 cycles) for the configuration handshake.
> > 
> > Instead of increasing the timeout to a huge fixed value for all clocks,
> > dynamically compute the required timeout based on both the old and new
> > clock rates, accounting for 3 cycles at each rate.
> > 
> > Based on a downstream patch by Mike Tipton:
> > https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/aa899c2d1fa31e247f04810f125ac9c60927c901
> > 
> > Fixes: bcd61c0f535a ("clk: qcom: Add support for root clock generators (RCGs)")
> > Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
> 
> Having Mike's s-o-b here is odd, given you've decided to go forward
> without his "From:"
> 

s/odd/wrong/ Please correct the author of the commit.

Note thought that it's good etiquette to document the changes you make
to Mike's original patch, by adding a line "[Xilin: changed x, y, z]"
between Mike's s-o-b and yours...until you end up having more changes
than the original author, then you're the author of the patch.

Regards,
Bjorn

> [...]
> > +static int get_update_timeout(const struct clk_rcg2 *rcg)
> 
> Let's tack on a '_us'
> 
> > +{
> > +	int timeout = 0;
> > +	unsigned long current_freq;
> > +
> > +	/*
> > +	 * The time it takes an RCG to update is roughly 3 clock cycles of the
> > +	 * old and new clock rates.
> > +	 */
> > +	current_freq = clk_hw_get_rate(&rcg->clkr.hw);
> > +	if (current_freq)
> > +		timeout += 3 * (USEC_PER_SEC / current_freq);
> > +	if (rcg->configured_freq)
> > +		timeout += 3 * (USEC_PER_SEC / rcg->configured_freq);
> 
> I suppose both are nonzero if we end up in this path but a check for zerodiv
> is always welcome
> 
> > +
> > +	return max(timeout, 500);
> > +}
> > +
> >  static int update_config(struct clk_rcg2 *rcg)
> >  {
> > -	int count, ret;
> > +	int timeout, count, ret;
> >  	u32 cmd;
> >  	struct clk_hw *hw = &rcg->clkr.hw;
> >  	const char *name = clk_hw_get_name(hw);
> > @@ -123,8 +141,10 @@ static int update_config(struct clk_rcg2 *rcg)
> >  	if (ret)
> >  		return ret;
> >  
> > +	timeout = get_update_timeout(rcg);
> 
> You can just assign count = get_update_timeout() below since you're not
> reusing this value
> 
> Konrad

  reply	other threads:[~2026-04-09  1:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-06 15:54 [PATCH 0/5] clk: qcom: Fix RCG/branch MND divider and timeout issues Xilin Wu
2026-04-06 15:54 ` [PATCH 1/5] clk: qcom: clk-rcg2: fix clk_rcg2_calc_mnd() producing wrong M/N/pre_div Xilin Wu
2026-04-06 15:54 ` [PATCH 2/5] clk: qcom: clk-rcg2: use 64-bit arithmetic in set_duty_cycle() Xilin Wu
2026-04-07 10:52   ` Konrad Dybcio
2026-04-06 15:54 ` [PATCH 3/5] clk: qcom: clk-branch: calculate timeout based on clock frequency Xilin Wu
2026-04-06 15:54 ` [PATCH 4/5] clk: qcom: clk-rcg2: " Xilin Wu
2026-04-07 10:13   ` Konrad Dybcio
2026-04-09  1:55     ` Bjorn Andersson [this message]
2026-04-09  3:32       ` Xilin Wu
2026-04-06 15:54 ` [PATCH 5/5] clk: qcom: clk-rcg2: fix set_duty_cycle() integer overflow in boundary checks Xilin Wu
2026-04-07 10:05   ` Konrad Dybcio

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=adcGdXeqltQVwPLz@baldur \
    --to=andersson@kernel.org \
    --cc=dsankouski@gmail.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=mturquette@linaro.org \
    --cc=quic_mdtipton@quicinc.com \
    --cc=quic_tdas@quicinc.com \
    --cc=sboyd@codeaurora.org \
    --cc=sboyd@kernel.org \
    --cc=sophon@radxa.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.