From: Nishanth Menon <nm@ti.com> To: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com>, <linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>, Nishanth Menon <nm@ti.com> Subject: [RFC PATCH] regulator: core: allow consumers to request to closes step voltage Date: Wed, 19 Jun 2013 14:17:54 -0500 [thread overview] Message-ID: <1371669474-24473-1-git-send-email-nm@ti.com> (raw) Regulator consumers are not aware of the characteristics of regulator used to supply. For example: consumerX requests for voltage min_uV = 500mV, max_uV = 500mV On a regulator which has a step size of 10mV, this can be exactly achieved. However, on a regulator which is non-exact divider step size (example 12.66mV step size), the closest achievable would be 506.4. regulator_set_voltage_tol does not work out either as <500mV is not an operational voltage. Account for step size accuracy when exact voltage requests are send for step based regulators. Signed-off-by: Nishanth Menon <nm@ti.com> --- The specific example I faced was using cpufreq-cpu0 driver with voltages for OPPs for MPU rail and attempting the common definitions against voltages that are non-exact multiples of stepsize of PMIC. The alternative would be implement custom set_voltage (as againsta simpler set_voltage_sel and using linear map/list functions) for the regulator which will account for the same. Yet another alternative might be to introduce yet another custom function similar to regulator_set_voltage_tol which accounts for this. something like: regulator_set_voltage_floor(regulator, voltage, tol) or something to that effect. drivers/regulator/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 288c75a..98c96b2 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2407,6 +2407,9 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev, } } else if (rdev->desc->ops->set_voltage_sel) { + if (min_uV == max_uV && rdev->desc->uV_step) + max_uV += rdev->desc->uV_step; + if (rdev->desc->ops->map_voltage) { ret = rdev->desc->ops->map_voltage(rdev, min_uV, max_uV); -- 1.7.9.5
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com> To: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, Nishanth Menon <nm@ti.com> Subject: [RFC PATCH] regulator: core: allow consumers to request to closes step voltage Date: Wed, 19 Jun 2013 14:17:54 -0500 [thread overview] Message-ID: <1371669474-24473-1-git-send-email-nm@ti.com> (raw) Regulator consumers are not aware of the characteristics of regulator used to supply. For example: consumerX requests for voltage min_uV = 500mV, max_uV = 500mV On a regulator which has a step size of 10mV, this can be exactly achieved. However, on a regulator which is non-exact divider step size (example 12.66mV step size), the closest achievable would be 506.4. regulator_set_voltage_tol does not work out either as <500mV is not an operational voltage. Account for step size accuracy when exact voltage requests are send for step based regulators. Signed-off-by: Nishanth Menon <nm@ti.com> --- The specific example I faced was using cpufreq-cpu0 driver with voltages for OPPs for MPU rail and attempting the common definitions against voltages that are non-exact multiples of stepsize of PMIC. The alternative would be implement custom set_voltage (as againsta simpler set_voltage_sel and using linear map/list functions) for the regulator which will account for the same. Yet another alternative might be to introduce yet another custom function similar to regulator_set_voltage_tol which accounts for this. something like: regulator_set_voltage_floor(regulator, voltage, tol) or something to that effect. drivers/regulator/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 288c75a..98c96b2 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2407,6 +2407,9 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev, } } else if (rdev->desc->ops->set_voltage_sel) { + if (min_uV == max_uV && rdev->desc->uV_step) + max_uV += rdev->desc->uV_step; + if (rdev->desc->ops->map_voltage) { ret = rdev->desc->ops->map_voltage(rdev, min_uV, max_uV); -- 1.7.9.5
next reply other threads:[~2013-06-19 19:18 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-06-19 19:17 Nishanth Menon [this message] 2013-06-19 19:17 ` [RFC PATCH] regulator: core: allow consumers to request to closes step voltage Nishanth Menon 2013-06-19 22:38 ` Mark Brown 2013-06-20 12:45 ` Nishanth Menon 2013-06-20 12:45 ` Nishanth Menon 2013-06-20 21:43 ` Nishanth Menon 2013-06-20 21:43 ` Nishanth Menon 2013-06-20 21:43 ` Nishanth Menon 2013-06-21 9:51 ` Mark Brown 2013-06-21 12:43 ` Nishanth Menon 2013-06-21 12:43 ` Nishanth Menon 2013-06-21 14:30 ` Mark Brown
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=1371669474-24473-1-git-send-email-nm@ti.com \ --to=nm@ti.com \ --cc=broonie@kernel.org \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.