linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan@gerhold.net>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-pm@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Stephan Gerhold <stephan.gerhold@kernkonzept.com>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] OPP: Use _set_opp_level() for single genpd case
Date: Wed, 25 Oct 2023 18:16:23 +0200	[thread overview]
Message-ID: <ZTk_M0JFdAg7FR7E@gerhold.net> (raw)
In-Reply-To: <20231025152431.bhdv772dwbufocck@vireshk-i7>

On Wed, Oct 25, 2023 at 08:54:31PM +0530, Viresh Kumar wrote:
> On 25-10-23, 15:47, Stephan Gerhold wrote:
> > FWIW I'm hitting this WARNing when trying to set up the parent domain
> > setup for CPR->RPMPD(MX) on MSM8916 that I discussed with Uffe recently
> > [1]. I know, me and all my weird OPP setups. :'D
> > 
> > Basically, I have cpufreq voting for performance states of the CPR genpd
> > (via required-opps). CPR is supposed to have <&rpmpd MSM8916_VDDMX_AO>
> > as parent genpd and translates to the parent performance state using the
> > "required-opps" in the *CPR* OPP table:
> > 
> > 	cpr: power-controller@b018000 {
> > 		compatible = "qcom,msm8916-cpr", "qcom,cpr";
> > 		reg = <0x0b018000 0x1000>;
> > 		/* ... */
> > 		#power-domain-cells = <0>;
> > 		operating-points-v2 = <&cpr_opp_table>;
> > 		/* Supposed to be parent domain, not consumer */
> > 		power-domains = <&rpmpd MSM8916_VDDMX_AO>;
> > 
> > 		cpr_opp_table: opp-table {
> > 			compatible = "operating-points-v2-qcom-level";
> > 
> > 			cpr_opp1: opp1 {
> > 				opp-level = <1>;
> > 				qcom,opp-fuse-level = <1>;
> > 				required-opps = <&rpmpd_opp_svs_soc>;
> > 			};
> > 			cpr_opp2: opp2 {
> > 				opp-level = <2>;
> > 				qcom,opp-fuse-level = <2>;
> > 				required-opps = <&rpmpd_opp_nom>;
> > 			};
> > 			cpr_opp3: opp3 {
> > 				opp-level = <3>;
> > 				qcom,opp-fuse-level = <3>;
> > 				required-opps = <&rpmpd_opp_super_turbo>;
> > 			};
> > 		};
> > 	};
> 
> I have forgotten a bit about this usecase. How exactly does the
> configurations work currently for this ? I mean genpd core must be
> setting the vote finally for only one of them or something else ?
> 

I'm not sure if I understand your question correctly. Basically, setting
<&rpmpd MSM8916_VDDMX_AO> as "parent genpd" of <&cpr> is supposed to
describe that there is a direct relationship between the performance
states of CPR and VDDMX. When changing the CPR performance state, VDDMX
should also be adjusted accordingly.

This is implemented in the genpd core in _genpd_set_performance_state().
It loops over the parent genpds, and re-evaluates the performance states
of each of them. Translation happens using genpd_xlate_performance_state()
which is just a direct call to dev_pm_opp_xlate_performance_state().
This will look up the required-opps from the OPP table above. However,
the genpd core calls ->set_performance_state() on the parent genpd
directly, so dev_pm_opp_set_opp() isn't involved in this case.

Overall the call sequence for a CPUfreq switch will look something like:

 - cpu0: dev_pm_opp_set_rate(998.4 MHz)
  - cpu0: _set_required_opps(opp-998400000)
   - genpd:1:cpu0: dev_pm_opp_set_opp(&cpr_opp3)
    - genpd:1:cpu0: _set_opp_level(&cpr_opp3)
     - cpr: _genpd_set_performance_state(3)

      # genpd: translate & adjust parent performance states
      - cpr: genpd_xlate_performance_state(parent=VDDMX_AO)
             => &rpmpd_opp_super_turbo = 6
       - VDDMX_AO: _genpd_set_performance_state(6)
        - rpmpd: ->set_performance_state(VDDMX_AO, 6)

      # genpd: change actual performance state
      - cpr: ->set_performance_state(cpr, 3)

Before the discussion with Uffe I did not describe this relationship
between CPR<->VDDMX as parent-child, I just had them as two separate
power domains in the CPU OPP table. That worked fine too but Uffe
suggested the parent-child representation might be better.
   
Does that help or were you looking for something else? :D

Thanks,
Stephan

  reply	other threads:[~2023-10-25 16:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 10:21 [RFT PATCH 0/2] OPP: Simplify required-opp handling Viresh Kumar
2023-10-19 10:22 ` [PATCH 1/2] OPP: Use _set_opp_level() for single genpd case Viresh Kumar
2023-10-19 11:16   ` Ulf Hansson
2023-10-20  3:45     ` Viresh Kumar
2023-10-20 10:02       ` Ulf Hansson
2023-10-20 10:56         ` Viresh Kumar
2023-10-20 11:09           ` Ulf Hansson
2023-10-25  6:54     ` Viresh Kumar
2023-10-25 10:40       ` Ulf Hansson
2023-10-25 10:48         ` Viresh Kumar
2023-10-25 13:47         ` Stephan Gerhold
2023-10-25 15:24           ` Viresh Kumar
2023-10-25 16:16             ` Stephan Gerhold [this message]
2023-10-26  9:53           ` Ulf Hansson
2023-10-30 10:29             ` Viresh Kumar
2023-11-03 11:58               ` Ulf Hansson
2023-11-06  7:08                 ` Viresh Kumar
2023-11-10 13:50                   ` Ulf Hansson
2023-11-15  5:32                     ` Viresh Kumar
2023-11-16 10:44                       ` Viresh Kumar
2023-10-19 10:22 ` [PATCH 2/2] OPP: Call dev_pm_opp_set_opp() for required OPPs Viresh Kumar
2023-10-24 11:18   ` Stephan Gerhold
2023-10-25  7:36     ` Viresh Kumar
2023-10-25 12:17       ` Stephan Gerhold
2023-10-25 15:20         ` Viresh Kumar
2023-10-25 16:03           ` Ulf Hansson
2023-10-26  7:44             ` Viresh Kumar
2023-10-25 13:51   ` Ulf Hansson
2023-10-25 15:09     ` Viresh Kumar

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=ZTk_M0JFdAg7FR7E@gerhold.net \
    --to=stephan@gerhold.net \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=nm@ti.com \
    --cc=rafael@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=stephan.gerhold@kernkonzept.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.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;
as well as URLs for NNTP newsgroup(s).