From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Michael Hennerich <michael.hennerich@analog.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
Jonathan Cameron <jic23@cam.ac.uk>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"device-drivers-devel@blackfin.uclinux.org"
<device-drivers-devel@blackfin.uclinux.org>
Subject: Re: voltage and current regulator framework: specifying negative voltages
Date: Thu, 14 Apr 2011 15:02:29 +0100 [thread overview]
Message-ID: <20110414140229.GC7890@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4DA6D01B.9080202@analog.com>
On Thu, Apr 14, 2011 at 12:44:43PM +0200, Michael Hennerich wrote:
> On 04/13/2011 07:24 PM, Mark Brown wrote:
Please cut irrelevant context from your replies.
> >>> Updating the core to allow negative and zero voltages, is not straight
> >>> forward.
> >>> There are more issues with constrain checking and I currently can't
> >>> oversee all side
> > What are the issues that you see?
> In case the output voltage can be negative, the input voltage may be
> negative as well.
> In functions drms_uA_update() and regulator_set_optimum_mode(), the
> input supply voltage
> is checked for being > 0, if that fails it uses the constrains->input_uV
> instead...
None of this seems particularly complicated to deal with, it's not a
massive change in the architecture of the code or anything - it's all
just refactoring interfaces and implementations a bit.
> BTW: Function drms_uA_update() looks suspicious.
> /* get input voltage */
> input_uV = 0;
> if (rdev->supply)
> input_uV = _regulator_get_voltage(rdev);
> it checks for rdev->supply but later uses rdev, which will ultimately
> mean input_uV == output_uV.
There's very few users of supplies in mainline and no users at all of
the optimal mode stuff.
prev parent reply other threads:[~2011-04-14 14:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 11:08 voltage and current regulator framework: specifying negative voltages Hennerich, Michael
2011-04-12 15:21 ` Mark Brown
2011-04-13 12:22 ` Michael Hennerich
2011-04-13 13:43 ` Liam Girdwood
2011-04-13 17:24 ` Mark Brown
2011-04-14 10:44 ` Michael Hennerich
2011-04-14 14:02 ` Mark Brown [this message]
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=20110414140229.GC7890@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=device-drivers-devel@blackfin.uclinux.org \
--cc=jic23@cam.ac.uk \
--cc=linux-iio@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=michael.hennerich@analog.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 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.