All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Stephan Gerhold <stephan@gerhold.net>,
	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: Mon, 6 Nov 2023 12:38:30 +0530	[thread overview]
Message-ID: <20231106070830.7sd3ux3nvywpb54z@vireshk-i7> (raw)
In-Reply-To: <CAPDyKFrn97POKuNc3cMM9TOaw-f-ufLwYtUY8_L2w8+hzECWOA@mail.gmail.com>

On 03-11-23, 12:58, Ulf Hansson wrote:
> Are you saying that the OPP library should be capable of managing the
> parent-clock-rates too, when there is a new rate being requested for a
> clock that belongs to an OPP? To me, that sounds like replicating
> framework specific knowledge into the OPP library, no? Why do we want
> this?

I am surely not touching clocks or any other framework :)

> Unless I totally misunderstood your suggestion, I think it would be
> better if the OPP library remained simple and didn't run recursive
> calls, but instead relied on each framework to manage the aggregation
> and propagation to parents.

I see your point and agree with it.

Here is the problem and I am not very sure what's the way forward for this then:

- Devices can have other devices (like caches) or genpds mentioned via
  required-opps.

- Same is true for genpds, they can also have required-opps, which may or may not
  be other genpds.

- When OPP core is asked to set a device's OPP, it isn't only about performance
  level, but clk, level, regulator, bw, etc. And so a full call to
  dev_pm_opp_set_opp() is required.

- The OPP core is going to run the helper recursively only for required-opps and
  hence it won't affect clock or regulators.

- But it currently affects genpds as they are mentioned in required-opps.

- Skipping the recursive call to a parent genpd will require a special hack,
  maybe we should add it, I am just discussing it if we should or if there is
  another way around this.

-- 
viresh

  reply	other threads:[~2023-11-06  7:08 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
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 [this message]
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=20231106070830.7sd3ux3nvywpb54z@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --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=stephan@gerhold.net \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@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 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.