Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1245566 > unrolled thread

[PATCH 5/8] regulator: introduce regulator_get_voltage_floor

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 5/8] regulator: introduce regulator_get_voltage_floor Sascha Hauer <s.hauer@pengutronix.de> - 2015-10-13 12:50 +0200
    Re: [PATCH 5/8] regulator: introduce regulator_get_voltage_floor Mark Brown <broonie@kernel.org> - 2015-10-16 19:00 +0200

#1245566 — [PATCH 5/8] regulator: introduce regulator_get_voltage_floor

Currently when we call set_voltage on a regulator we do not know
with which voltage we will end up with. Once we start with propagating
voltage changes to the supplies we have to know that before we start
doing anything. This patch introduces regulator_get_voltage_floor which
calculates the minimum voltage a regulator supports which is higher
than a given minimum voltage.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/regulator/core.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index bd66097..6623538 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2764,6 +2764,45 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 	return ret;
 }
 
+/*
+ * Return the minimum voltage supported by a regulator that is higher or equal
+ * to a given voltage.
+ */
+static int regulator_get_voltage_floor(struct regulator *regulator, int min_uV)
+{
+	struct regulator_dev *rdev = regulator->rdev;
+	int num_voltages;
+	int best = INT_MAX;
+	int max_uV = INT_MAX;
+	int i, now, ret;
+
+	/* constraints check */
+	ret = regulator_check_voltage(rdev, &min_uV, &max_uV);
+	if (ret < 0)
+		return ret;
+
+	ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
+	if (ret < 0)
+		return ret;
+
+	num_voltages = regulator_count_voltages(regulator);
+	if (num_voltages < 0)
+		return num_voltages;
+
+	for (i = 0; i < num_voltages; i++) {
+		now = _regulator_list_voltage(regulator, i, 0);
+		if (now < 0)
+			continue;
+		if (now < best && now >= min_uV)
+			best = now;
+	}
+
+	if (best > max_uV)
+		return -EINVAL;
+
+	return best;
+}
+
 static int regulator_set_voltage_unlocked(struct regulator *regulator,
 					  int min_uV, int max_uV)
 {
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1248985

[Multipart message — attachments visible in raw view] — view raw

On Tue, Oct 13, 2015 at 12:45:28PM +0200, Sascha Hauer wrote:

> +	num_voltages = regulator_count_voltages(regulator);
> +	if (num_voltages < 0)
> +		return num_voltages;

> +	for (i = 0; i < num_voltages; i++) {
> +		now = _regulator_list_voltage(regulator, i, 0);
> +		if (now < 0)
> +			continue;
> +		if (now < best && now >= min_uV)
> +			best = now;
> +	}

Why is this not a factoring out of existing code (indeed it is itself a
reimplementation of regulator_map_voltage_iterate())?  This will also be
a substantial performance loss in cases where we have a known mapping
function - we should use a map_voltage() operation if one exists like we
do in _do_set_voltage().  That has logic to handle missing mapping
functions as a transition measure, now I look at it we should probably
remove that code and just require that the mapping function is set if
appropriate.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web