[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f139041f-452a-46d9-b5af-a5ddef29c705@linaro.org>
Date: Wed, 6 Sep 2023 09:33:38 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Stephen Boyd <sboyd@...nel.org>,
Devi Priya <quic_devipriy@...cinc.com>, agross@...nel.org,
andersson@...nel.org, linux-arm-msm@...r.kernel.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
mturquette@...libre.com
Cc: quic_saahtoma@...cinc.com
Subject: Re: [PATCH V2] clk: qcom: clk-alpha-pll: Use determine_rate instead
of round_rate
On 5.09.2023 22:40, Stephen Boyd wrote:
> Quoting Devi Priya (2023-09-01 00:00:41)
>> The round_rate() API returns a long value as the errors are reported using
>> negative error codes. This leads to long overflow when the clock rate
>> exceeds 2GHz.As the clock controller treats the clock rate above signed
>> long max as an error, use determine_rate in place of round_rate as the
>> determine_rate API does not possess such limitations.
>
> Does this fix something, or is it preparing for PLLs that run faster
> than 2GHz?
I did some grepping and we already have multiple of these.
E.g. SM8250 CAMCC PLL2 (zonda) goes (or well, should go) up to 3.6 GHz.
Today, only stromer PLL uses determine rate, but perhaps all of them
should.
I would not at all be surprised if many otherwise inexplicable bugs
went away with that change.
Konrad
Powered by blists - more mailing lists