cpufreq.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Mark Brown <broonie@kernel.org>,
	Mike Turquette <mturquette@linaro.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: [RFC PATCH 0/6] PM: introduce voltage domain abstraction
Date: Tue, 18 Feb 2014 14:32:17 -0600	[thread overview]
Message-ID: <1392755543-28335-1-git-send-email-nm@ti.com> (raw)

Hi,

On many SoCs such as OMAP, hardware blocks are isolated into voltage
domains allowing for individual tweaks for optimal power-performance
tradeoffs. Frameworks such as cpufreq, devfreq provide a top level
control of these hardware blocks. Most SoCs have different knobs to
fine tune the voltages. They may supply multiple supplies to various
voltage planes on the same voltage domains.

Regulator framework provides us a with an appropriate representation
of consumer model, however, we lack the abstraction necessary to
isolate the necessary sequencing for a specific voltage domain.

There has been few attempts previously taken such as [3] [4],
this series is a further development of of Mike's series[1] where
cpufreq-cpu0 driver was first targetted with clk notifiers. While I do
understand the concerns Mike has in [2], this could be a base on which
further work may be done.

In a nutshell, this (for cpufreq-cpu0 as an example):
maintains the legacy definitions used by cpufreq/devfreq such as:
&cpu0 {
	cpu0-supply = <&regulator_x>;
};

on other SoCs where this might turn out to be a more detailed
implementation,
&cpu0 {
	cpu0-voltdm = <&voltdm_x>;
};

To enure this is split off from clk framework, I chose
drivers/power/voltdm as the location for the new files, I'd love to
hear opinions and suggestions on the approach.

The series is based on 3.14-rc3 and is available here:
https://github.com/nmenon/linux-2.6-playground/commits/push/voltdm-notifier-rfc

A testing branch for Beagle-XM (OMAP3630 as testbed):
	https://github.com/nmenon/linux-2.6-playground/commits/testing/beagle-xm-voltdm-notifier-rfc
	Log: http://slexy.org/view/s20TgkN7kf

NOTE: TI platforms potentially need further development, however, this
forms the basis of the development.

Mike Turquette (2):
  PM / Voltagedomain: Add generic clk notifier handler for regulator
    based dynamic voltage scaling
  cpufreq: cpufreq-cpu0: use clk rate-change notifiers

Nishanth Menon (4):
  PM / Voltagedomain: introduce voltage domain driver support
  devicetree: bindings: add documentation for voltagedomain
  PM / Voltagedomain: introduce basic voltage domain support for OMAP
  devicetree: bindings: voltagedomain: add bindings for OMAP compatible
    SoCs

 .../bindings/power/voltdm/voltage_domain.txt       |   65 +++
 .../bindings/power/voltdm/voltdm_omap.txt          |   24 +
 drivers/cpufreq/Kconfig                            |    1 +
 drivers/cpufreq/cpufreq-cpu0.c                     |  140 ++----
 drivers/power/Kconfig                              |    1 +
 drivers/power/Makefile                             |    1 +
 drivers/power/voltdm/Kconfig                       |   19 +
 drivers/power/voltdm/Makefile                      |    6 +
 drivers/power/voltdm/core.c                        |  508 ++++++++++++++++++++
 drivers/power/voltdm/voltage_domain_private.h      |   86 ++++
 drivers/power/voltdm/voltdm_omap.c                 |  287 +++++++++++
 include/linux/pm_voltage_domain.h                  |   47 ++
 12 files changed, 1086 insertions(+), 99 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt
 create mode 100644 Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt
 create mode 100644 drivers/power/voltdm/Kconfig
 create mode 100644 drivers/power/voltdm/Makefile
 create mode 100644 drivers/power/voltdm/core.c
 create mode 100644 drivers/power/voltdm/voltage_domain_private.h
 create mode 100644 drivers/power/voltdm/voltdm_omap.c
 create mode 100644 include/linux/pm_voltage_domain.h

[1] https://lkml.org/lkml/2013/7/7/110 (original RFC)
[2] http://marc.info/?l=linux-arm-kernel&m=137947787621572&w=2 (runtime pm should enable regulator)
[3] http://marc.info/?t=136603111700006&r=1&w=2
[4] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/dvfs.c;hb=p-linux-omap-3.4
-- 
1.7.9.5


             reply	other threads:[~2014-02-18 20:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 20:32 Nishanth Menon [this message]
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
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=1392755543-28335-1-git-send-email-nm@ti.com \
    --to=nm@ti.com \
    --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=mturquette@linaro.org \
    --cc=myungjoo.ham@samsung.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 read-only IMAP folder(s) and NNTP newsgroup(s).