mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Konrad Dybcio <konradybcio@kernel.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Brian Masney <bmasney+clk@redhat.com>,
	Jerome Brunet <jbrunet+clk@baylibre.com>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Pavel Machek <pavel@kernel.org>, Len Brown <lenb@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Johan Hovold <johan@kernel.org>, Ulf Hansson <ulfh@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Abel Vesa <abelvesa@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Mike Tipton <mike.tipton@oss.qualcomm.com>,
	Taniya Das <taniya.das@oss.qualcomm.com>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, driver-core@lists.linux.dev,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH RFC 03/16] OPP: Retry failed default single-clock transitions
Date: Thu, 22 Oct 2026 09:22:23 +0200	[thread overview]
Message-ID: <11d992ca-f666-4a4b-a511-ec12335e6960@oss.qualcomm.com> (raw)
In-Reply-To: <njgant4vjdowkfe4milfhpeknosxxyalcfuf5p25c2t2sn6ffp@esokxr6ridc4>

On 10/14/26 6:32 PM, Dmitry Baryshkov wrote:
> On Wed, Oct 14, 2026 at 06:14:43PM +0200, Konrad Dybcio wrote:
>> On 10/14/26 3:35 PM, Dmitry Baryshkov wrote:
>>> On Wed, Oct 14, 2026 at 02:19:03PM +0200, Konrad Dybcio wrote:
>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>
>>>> A failed OPP transition need not leave the clock at the last successful
>>>> OPP's frequency. If hardware changed before the error, the default
>>>> single-clock path can subsequently skip a necessary retry because its
>>>
>>> What is a necessary retry? Shouldn't it be: try, rollback if it fails?
>>
>> The failure scenario is:
>>
>> opp-table {
>> 	opp-400000000 {
>> 		// low
>> 	};
>>
>> 	opp-1000000000 {
>> 		// high
>> 	};
>> }';
>>
>> 1. The device is running at Low. OPP caches 400 MHz and the Low OPP.
>> 2. A driver requests High.
>> - OPP raises the voltage to 0.95 V.
>> - clk_set_rate(..., 1 GHz) changes the clock, but returns an error
> 
> I thought that your previous patches actively target this. I.e. if there
> is an error, CCF should retract the changes for as much as it can
> (assuming that there is no extra error on the reverting of the clocks).

Right, that's at the CCF layer. OPP also has the same problem and
needs a similar solution. Perhaps once all consumers are migrated
to clk-dvfs this won't be a problem anymore, but that's Qualcomm
only.


>> - Assume clk_get_rate() can report the resulting 1 GHz rate.
>> 3. The transition returns an error, so current_opp still points to Low.
>> 4. The caller tries to recover by requesting Low again.
>>
>> Perhaps I should have included that in the commit message.
> 
> I think, if something changes the state, but returns an error, it's more
> or less... an error. Or a bug.

As we've chatted offline.. you can try to unroll.. but if you error
out while unrolling you have to unroll the unroll. And if you error
out during unrolling of the unrolling...

Konrad

  reply	other threads:[~2026-10-22  7:22 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 12:19 [RFC PATCH 00/16] Centralize the ownership of power rail votes for Qualcomm clocks Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 01/16] clk: Propagate rate programming failures Konrad Dybcio
2026-10-14 13:25   ` Dmitry Baryshkov
2026-10-14 12:19 ` [PATCH RFC 02/16] clk: Acquire resources for clock transitions Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 03/16] OPP: Retry failed default single-clock transitions Konrad Dybcio
2026-10-14 13:35   ` Dmitry Baryshkov
2026-10-14 16:14     ` Konrad Dybcio
2026-10-14 16:32       ` Dmitry Baryshkov
2026-10-22  7:22         ` Konrad Dybcio [this message]
2026-10-14 12:19 ` [PATCH RFC 04/16] pmdomain: core: Support named indexed virtual attachments Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 05/16] pmdomain: core: Support subdomains without pstate propagation Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 06/16] pmdomain: core: Support indexed power-domain attachment lists Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 07/16] clk: qcom: Add clock-owned GenPD DVFS aggregation Konrad Dybcio
2026-10-14 14:36   ` Dmitry Baryshkov
2026-10-14 15:26     ` Konrad Dybcio
2026-10-14 16:30       ` Dmitry Baryshkov
2026-10-14 16:45         ` Konrad Dybcio
2026-10-14 17:31           ` Dmitry Baryshkov
2026-10-15  8:08             ` Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 08/16] clk: qcom: dvfs: Add debugfs Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 09/16] clk: qcom: clk-alpha-pll: Add DVFS (un)prepare Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 10/16] clk: qcom: clk-alpha-pll: Vote for the PLL calibration frequency Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 11/16] clk: qcom: gdsc: Make GDSC parenting optional Konrad Dybcio
2026-10-14 14:17   ` Dmitry Baryshkov
2026-10-14 14:20     ` Konrad Dybcio
2026-10-14 14:34       ` Dmitry Baryshkov
2026-10-14 14:36         ` Konrad Dybcio
2026-10-14 12:19 ` [PATCH RFC 12/16] clk: qcom: gdsc: Link required power domains Konrad Dybcio
2026-10-14 12:19 ` [PATCH DNM RFC 13/16] arm64: dts: qcom: sm8650: Describe clock controller power rails Konrad Dybcio
2026-10-14 14:19   ` Dmitry Baryshkov
2026-10-14 14:20     ` Konrad Dybcio
2026-10-14 14:33       ` Dmitry Baryshkov
2026-10-14 14:36         ` Konrad Dybcio
2026-10-14 15:01           ` Dmitry Baryshkov
2026-10-14 15:23             ` Konrad Dybcio
2026-10-14 12:19 ` [PATCH DNM RFC 14/16] clk: qcom: Enable clk-dvfs on SM8650 Konrad Dybcio
2026-10-14 14:40   ` Dmitry Baryshkov
2026-10-14 15:22     ` Konrad Dybcio
2026-10-14 16:35       ` Dmitry Baryshkov
2026-10-14 16:42         ` Konrad Dybcio
2026-10-14 12:19 ` [PATCH DNM RFC 15/16] arm64: dts: qcom: sm8650: Drop required-opps Konrad Dybcio
2026-10-14 14:23   ` Dmitry Baryshkov
2026-10-14 14:33     ` Konrad Dybcio
2026-10-14 12:19 ` [PATCH DNM RFC 16/16] pmdomain: qcom: rpmhpd: Stop forwarding MMCX pstate to CX Konrad Dybcio
2026-10-14 14:37 ` [RFC PATCH 00/16] Centralize the ownership of power rail votes for Qualcomm clocks Dmitry Baryshkov
2026-10-14 16:19   ` Konrad Dybcio
2026-10-15 10:57 ` Taniya Das

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=11d992ca-f666-4a4b-a511-ec12335e6960@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=abelvesa@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bmasney+clk@redhat.com \
    --cc=conor+dt@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=jbrunet+clk@baylibre.com \
    --cc=johan@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mike.tipton@oss.qualcomm.com \
    --cc=neil.armstrong@linaro.org \
    --cc=nm@ti.com \
    --cc=pavel@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=taniya.das@oss.qualcomm.com \
    --cc=ulfh@kernel.org \
    --cc=vireshk@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®