From: Mark Brown <broonie@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Inderpal Singh <inderpal.s@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-pm@vger.kernel.org,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Pawel Moll <pawel.moll@arm.com>
Subject: Re: [RFC PATCH] regulator: virtual: Introduce a new virtual locker regulator type
Date: Fri, 2 May 2014 09:51:32 -0700 [thread overview]
Message-ID: <20140502165132.GH3245@sirena.org.uk> (raw)
In-Reply-To: <CAD=FV=X5vGgZOxbRb808R9CSnGLPD9Tc77VMO5B3f3FS0jwk6Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]
On Fri, May 02, 2014 at 09:13:39AM -0700, Doug Anderson wrote:
> On Wed, Apr 30, 2014 at 6:28 PM, Mark Brown <broonie@kernel.org> wrote:
> > I glanced at this briefly and couldn't really understand what it was
> > supposed to do from a quick glance but I do tend to agree that it's too
> > complex and confusing. Quite what the virtual regulator is supposed to
> > represent or how it is used is distinctly non-obvious.
> From my understanding, there are parts internal to the SoC where
> something powered by the INT rail looks at an signal based on the ARM
> rail, or vice versa. If the two voltages are too vastly different
> then you get into trouble.
That bit is totally clear and normal, what's not at all obvious is what
the virtual regulator is really representing and how it will be used by
software at runtime to achieve this goal. In general introducing purely
virtual things into the device tree is not a good sign for things like
OS independence.
> Mark Brown: did the bindings above seem sane to you? I can clean them
> up a bit and explain more:
Yes, that's one of the suggestions I proposed...
> - regulator-lock-to: A list of regulators to monitor. If they ever
> are greater than our voltage + the corresponding "lock-within" then we
> should bump up our voltage. We'll bump back down if/when the
> monitored regulator falls again.
This isn't a good name, there is also a common feature in hardware where
two regulators are run in parallel to deliver higher current. The idea
is fine though.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2014-05-02 16:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 5:35 Inderpal Singh
2014-04-30 18:56 ` Doug Anderson
2014-05-01 1:28 ` Mark Brown
2014-05-02 16:13 ` Doug Anderson
2014-05-02 16:51 ` 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=20140502165132.GH3245@sirena.org.uk \
--to=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=inderpal.s@samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@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: 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
all inboxes | Powered by JetHome®