Re: [RFD] Voltage dependencies for clocks (DVFS)

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Michael Turquette <mturquette@baylibre.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	grahamr@codeaurora.org,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	Doug Anderson <dianders@chromium.org>,
	tdas@codeaurora.org, Rajendra Nayak <rnayak@codeaurora.org>,
	anischal@codeaurora.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	amit.kucheria@linaro.org, linux-clk-owner@vger.kernel.org
Subject: Re: [RFD] Voltage dependencies for clocks (DVFS)
Date: Wed, 19 Sep 2018 09:05:59 +0200	[thread overview]
Message-ID: <CAMuHMdWdPHOhZFCnswaYoUgbDSaEAOzgN02S3vbww4QKkX69Aw@mail.gmail.com> (raw)
In-Reply-To: <20180918230023.67076.42969@harbor.lan>

On Wed, Sep 19, 2018 at 1:01 AM Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Ulf Hansson (2018-08-23 06:20:11)
> > Anyway, in regards to control the performance state for these clock
> > controller devices, to me it seems like there are no other way, but
> > explicitly allow clock drivers to call an "OPP API" to request a
> > performance state. Simply, because it's the clock driver that needs
> > the performance state for its device. Whether the "OPP API" is the
> > new, dev_pm_genpd_set_performance_state() or something not even
> > invented yet, is another question.
>
> I completely agree, with the exception that I don't think it will be an
> "OPP API" but instead I hope it will be some runtime pm performance api.
>
> > My conclusion so far is, that we seems to fall back to a potential
> > locking problem. In regards to that, I am wondering whether that is
> > actually more of hypothetical problem than a real problem for your
> > case.
>
> For reference, this is why we allow reentrancy into the clock framework.
> It is common that consumer A calls clk_set_rate to set clock X to a
> rate, but in order for clock X to acheive that rate the clock provider
> might need to call clk_set_rate on another clock. We support reentrancy
> for this type of case.
>
> The problem described by Graham seems analogous. There are times when a
> performance provider itself will need to adjust it's own performance (as
> consumed by some other parent provider). I'm under the impression that
> runtime pm allows reentrancy and genpd allows for nested genpds, so
> hopefully this should Just Work.

BTW, from time to time, lockdep spews out warnings about genpd/clock
interaction. I believe they are false positives.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds