From: Mike Turquette <mturquette@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-omap@vger.kernel.org, Nishanth Menon <nm@ti.com>
Subject: Re: [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
Date: Mon, 24 Feb 2014 21:51:42 -0800 [thread overview]
Message-ID: <20140225055142.22529.21814@quantum> (raw)
In-Reply-To: <1392755543-28335-2-git-send-email-nm@ti.com>
Quoting Nishanth Menon (2014-02-18 12:32:18)
> From: Mike Turquette <mturquette@linaro.org>
>
> This patch provides helper functions for drivers that wish to scale
> voltage through the clock rate-change notifiers. The approach taken
> is that the user-driver(cpufreq/devfreq) do not care about the
> details of the OPP table, nor does it care about handling the voltage
> regulator directly.
>
> By using the clk notifier flags, we are able to sequence the operations
> in the right order. The current logic is heavily influenced by
> implementation done in cpufreq-cpu0.
>
> [nm@ti.com: Fixes in logic, and broken out from clk to allow building
> a generic voltagedomain solution independent of cpufreq]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Mike Turquette <mturquette@linaro.org>
Not-signed-off-by: Mike Turquette <mturquette@linaro.org>
I haven't reviewed this series and it is a pretty big deviation from my
original RFC. You can have authorship of the patches if you want.
I'm not sure about trying to capture the "voltdm" as a core concept. It
feels a bit unwieldy to me. I have wondered about making an abstract
"performance domain" which is the dvfs analogue to generic power
domains. This a reasonable split since gpd are good for idle power
savings (e.g. clock gate, power gate, sleep state, etc) and "perf
domains" would be good for active power savings (dvfs).
Having a generic container for performance domains might make a good
place to stuff all of this glue logic that we keep running into (e.g.
CPU and GPU max frequencies that are related), and it might make another
nice knob for the thermal folks to use.
For the case of the OMAP voltage domains, it would be a place to stuff
all of the VC/VP -> ABB -> Smart Reflex AVS stuff.
Anyways, I don't have a real proposal. I just don't want my name on
these patches since they are really yours now. I might resurrect them
some day in a different context.
Regards,
Mike
next prev parent reply other threads:[~2014-02-25 5:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 20:32 [RFC PATCH 0/6] PM: introduce voltage domain abstraction Nishanth Menon
2014-02-18 20:32 ` [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling Nishanth Menon
2014-02-25 5:51 ` Mike Turquette [this message]
2014-02-25 20:56 ` Nishanth Menon
2014-02-27 2:34 ` Nishanth Menon
2014-02-27 5:00 ` Mike Turquette
2014-02-27 14:42 ` Nishanth Menon
2014-02-27 18:59 ` Felipe Balbi
2014-02-18 20:32 ` [RFC PATCH 2/6] cpufreq: cpufreq-cpu0: use clk rate-change notifiers Nishanth Menon
2014-02-18 20:32 ` [RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support Nishanth Menon
2014-02-24 1:58 ` Mark Brown
2014-02-24 14:38 ` Nishanth Menon
2014-03-03 3:54 ` Mark Brown
2014-03-10 17:11 ` Nishanth Menon
2014-03-10 17:22 ` Mark Brown
2014-03-10 17:41 ` Nishanth Menon
2014-03-10 18:01 ` Mark Brown
2014-03-10 19:25 ` Nishanth Menon
2014-03-19 22:35 ` Mike Turquette
2014-02-18 20:32 ` [RFC PATCH 4/6] devicetree: bindings: add documentation for voltagedomain Nishanth Menon
2014-02-18 20:32 ` [RFC PATCH 5/6] PM / Voltagedomain: introduce basic voltage domain support for OMAP Nishanth Menon
2014-02-18 20:32 ` [RFC PATCH 6/6] devicetree: bindings: voltagedomain: add bindings for OMAP compatible SoCs Nishanth Menon
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=20140225055142.22529.21814@quantum \
--to=mturquette@linaro.org \
--cc=broonie@kernel.org \
--cc=cpufreq@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.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).