linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>,
	"Gopinath, Thara" <thara@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"paul@pwsan.com" <paul@pwsan.com>,
	"Sripathy, Vishwanath" <vishwanath.bs@ti.com>,
	"Sawant, Anand" <sawant@ti.com>,
	"Cousson, Benoit" <b-cousson@ti.com>,
	Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Date: Wed, 24 Nov 2010 10:45:44 +0100	[thread overview]
Message-ID: <20101124104544.13da3cd2@surf> (raw)
In-Reply-To: <20100903182052.GB32226@rakim.wolfsonmicro.main>

Hello Mark,

On Fri, 3 Sep 2010 19:20:52 +0100
Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> Essentially all that needs doing is that when regulator_set_voltage() is
> called instead of merging with the machine constraints and applying the
> setting immediately we store the constraints that are specified in the
> consumer then iterate over all enabled consumers applying all the
> constraints that they've set in addition to those from the machine.
> This results in a configuration which is the lowest possible voltage
> which satisfies all the constraints that have been supplied and for
> supplies with only one consumer it gives the same behaviour as we have
> currently.

I went ahead and implemented this (without looking at previous existing
code since I couldn't find it). What about the following patch ?

I've tested it with a dummy platform driver and a dummy regulator
driver, making sure that the correct voltage gets set at the regulator
level. My testing had a device requesting a voltage [830000, 833000]
and another device [822000, 831000]. Without the patch, as the
regulator_set_voltage() gets called for the second device last, the
voltage is set at 822000 which is not acceptable for the first device.
With the patch, the 830000 voltage is kept, since it satisfies both
consumers. If the second device had [822000,828000] has its voltage
requirements, then regulator_set_voltage() would fail with -EINVAL since
it is not possible to find a voltage level that satisfies both
consumers.

If you're ok with it, I'll submit it the proper way.

Thanks,

Thomas


>From fa0edfc1a4428aead4502fcba248084c1194da53 Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni <t-petazzoni@ti.com>
Date: Wed, 24 Nov 2010 10:34:35 +0100
Subject: [PATCH] regulator: Take into account the requirements of all consumers

Extend the regulator_set_voltage() function to take into account the
voltage requirements of all consumers of the regulator being changed,
in order to set the voltage to the minimum voltage acceptable to all
consumers. The existing behaviour was that the latest
regulator_set_voltage() call would win over previous
regulator_set_voltage() calls even if setting the voltage to a
non-acceptable level from other consumers.

Signed-off-by: Thomas Petazzoni <t-petazzoni@ti.com>
---
 drivers/regulator/core.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f1d10c9..12a1cae 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -132,6 +132,28 @@ static int regulator_check_voltage(struct regulator_dev *rdev,
 	return 0;
 }
 
+/* Make sure we select a voltage that suits the needs of all
+ * regulator consumers
+ */
+static int regulator_check_consumers(struct regulator_dev *rdev,
+				     int *min_uV, int *max_uV)
+{
+	struct regulator *regulator;
+
+	list_for_each_entry(regulator, &rdev->consumer_list, list)
+	{
+		if (*max_uV > regulator->max_uV)
+			*max_uV = regulator->max_uV;
+		if (*min_uV < regulator->min_uV)
+			*min_uV = regulator->min_uV;
+	}
+
+	if (*min_uV > *max_uV)
+		return -EINVAL;
+
+	return 0;
+}
+
 /* current constraint check */
 static int regulator_check_current_limit(struct regulator_dev *rdev,
 					int *min_uA, int *max_uA)
@@ -1636,6 +1658,11 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
 		goto out;
 	regulator->min_uV = min_uV;
 	regulator->max_uV = max_uV;
+
+	ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
+	if (ret < 0)
+		goto out;
+
 	ret = rdev->desc->ops->set_voltage(rdev, min_uV, max_uV);
 
 out:
-- 
1.7.0.4



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  parent reply	other threads:[~2010-11-24  9:45 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-18 11:19 [PATCH 00/13] OMAP: Basic DVFS framework Thara Gopinath
2010-08-18 11:20 ` [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver Thara Gopinath
2010-08-27 23:53   ` Kevin Hilman
2010-08-30 22:56     ` Kevin Hilman
2010-09-16  9:59     ` Gopinath, Thara
2010-09-16 15:20       ` Kevin Hilman
2010-09-17 14:33         ` Gopinath, Thara
2010-09-01 22:51   ` Kevin Hilman
2010-09-02  7:43     ` Thomas Petazzoni
2010-09-02  8:17       ` Nishanth Menon
2010-09-02 10:00         ` Felipe Balbi
2010-09-02 10:17           ` Nishanth Menon
2010-09-02 10:28             ` Felipe Balbi
2010-09-02 10:40               ` Nishanth Menon
2010-09-02 11:16                 ` Felipe Balbi
2010-09-02 17:47         ` Kevin Hilman
2010-09-02 18:46           ` Nishanth Menon
2010-09-02 18:56             ` Kevin Hilman
2010-09-03  7:09     ` Gopinath, Thara
2010-09-03 16:41       ` Kevin Hilman
2010-09-03 17:30         ` Mark Brown
2010-09-03 18:00           ` Kevin Hilman
2010-09-03 18:20             ` Mark Brown
2010-09-06 19:59               ` Eduardo Valentin
2010-09-06 20:21                 ` Liam Girdwood
2010-09-06 21:21                 ` Mark Brown
2010-11-23  9:26               ` Thomas Petazzoni
2010-11-24  9:45               ` Thomas Petazzoni [this message]
2010-11-24  9:51                 ` Mark Brown
2010-09-03 18:27       ` Kevin Hilman
2010-09-06 11:01         ` Mark Brown
2010-08-18 11:20 ` [PATCH 02/13] OMAP: Introduce API in the OPP layer to find the opp entry corresponding to a voltage Thara Gopinath
2010-08-18 11:20 ` [PATCH 03/13] OMAP: Introduce voltage domain information in the hwmod structures Thara Gopinath
2010-08-18 11:20 ` [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain Thara Gopinath
2010-08-28  0:52   ` Kevin Hilman
2010-08-28  0:54     ` Kevin Hilman
2010-09-16 10:04     ` Gopinath, Thara
2010-09-16 15:22       ` Kevin Hilman
2010-09-17 14:48         ` Gopinath, Thara
2010-09-20 18:00           ` Kevin Hilman
2010-09-02  0:33   ` Kevin Hilman
2010-09-16 10:10     ` Gopinath, Thara
2010-09-16 15:23       ` Kevin Hilman
2010-08-18 11:20 ` [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures Thara Gopinath
2010-09-02 23:41   ` Kevin Hilman
2010-09-16 10:21     ` Gopinath, Thara
2010-09-16 15:28       ` Kevin Hilman
2010-09-17 14:55         ` Gopinath, Thara
2010-09-18 10:13           ` Cousson, Benoit
2010-09-20 17:35             ` Kevin Hilman
2010-09-29 11:16             ` Gopinath, Thara
2010-09-29 20:25               ` Cousson, Benoit
2010-08-18 11:20 ` [PATCH 06/13] OMAP: Voltage layer changes to support DVFS Thara Gopinath
2010-08-18 11:20 ` [PATCH 07/13] OMAP: Introduce dependent voltage domain support Thara Gopinath
2010-08-18 11:20 ` [PATCH 08/13] OMAP: Introduce device set_rate and get_rate Thara Gopinath
2010-08-18 11:20 ` [PATCH 09/13] OMAP: Disable smartreflex across DVFS Thara Gopinath
2010-08-18 11:20 ` [PATCH 10/13] OMAP3: Introduce custom set rate and get rate APIs for scalable devices Thara Gopinath
2010-08-31  0:06   ` Kevin Hilman
2010-08-18 11:20 ` [PATCH 11/13] OMAP3: Update cpufreq driver to use the new set_rate API Thara Gopinath
2010-08-18 11:20 ` [PATCH 12/13] OMAP3: Introduce voltage domain info in the hwmod structures Thara Gopinath
2010-08-18 11:20 ` [PATCH 13/13] OMAP3: Add voltage dependency table for VDD1 Thara Gopinath

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=20101124104544.13da3cd2@surf \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=b-cousson@ti.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=paul@pwsan.com \
    --cc=sawant@ti.com \
    --cc=thara@ti.com \
    --cc=vishwanath.bs@ti.com \
    /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).