From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
lrg@ti.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] regulator: max8973: add regulator driver support
Date: Tue, 20 Nov 2012 17:08:09 +0900 [thread overview]
Message-ID: <20121120080805.GU10560@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1211200840590.21420@axis700.grange>
[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]
On Tue, Nov 20, 2012 at 08:55:47AM +0100, Guennadi Liakhovetski wrote:
> On Tue, 20 Nov 2012, Mark Brown wrote:
> > The thing I'd like to see factored out here is the LRU mechanism,
> > otherwise I think the situation is pretty good. Some of the older
> > devices should use a different scheme to modern ones as the hardware
> > they have to interoperate is different.
> So, do you consider the LRU algorithm to be the preferred way to configure
> such regulators? I realise that in practice it will work well in most
Well, there's not really many other options.
> cases, usually users do only want to preconfigure such a regulator to 2
> fixed voltages and switch between them at runtime, right? OTOH, do you
> think it is too unlikely, that someone will want to switch, say, between 3
> voltages: X-Y-Z-X-Y-Z-X...? In this case the LRU will just lead to
> constantly reprogramming the regulator. Whereas if the user had a way to
> say "configure context A to X," "B to Y," and then only reprogram B
> between voltages Y and Z, we'd save 1/3 of re-configuration accesses?
> Maybe even in some such case, quickly switching to voltage X is more
> important than to voltage Y or Z.
Modern devices tend to use multiple GPIOs for this control for a jolly
good reason. If you've only got two levels then the wm831x algorithm is
probably the most sensible.
> > > > Add regulator driver for this device.
> > *ALWAYS* delete irrelevant text when replying.
> Not sure what you mean, sorry. If you mean all the text, that followed the
> above line, then it wasn't all irrelevant, there were more comments down
> there. OTOH, if you just meant, that I could have deleted even more text,
> than what I've done, then right, sorry, there's always a balance between
I actually thought you'd just quoted the entire mail and just deleted
the rest after a couple of screenfuls so a bit of both.
> deleting too little and too much, and the decision is subjective. I
> usually tend to keep somewhat more, tnan most would consider required, I
> think, it is easier to hit "Page Down" a couple more times, than to have
> to guess what the missing context was. But I'll try to reduce unneeded
> context next time.
The extra content is profoundly unhelpful to people reading on phones,
and to people on slow connections (I spend an awful lot of time in
hotels with dodgy internet access for example). It also (as happened to
me) makes it hard to find new comments in the middle of reams of stuff
you're paging down through.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-11-20 8:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-19 1:28 [PATCH] regulator: max8973: add regulator driver support Laxman Dewangan
2012-11-19 8:03 ` Mark Brown
2012-11-19 10:52 ` Guennadi Liakhovetski
2012-11-20 0:43 ` Mark Brown
2012-11-20 7:55 ` Guennadi Liakhovetski
2012-11-20 8:08 ` Mark Brown [this message]
2012-11-20 8:23 ` Guennadi Liakhovetski
2012-11-20 8:32 ` Mark Brown
2012-11-20 1:54 ` Laxman Dewangan
2012-11-20 9:42 ` Guennadi Liakhovetski
2012-11-23 0:29 ` Laxman Dewangan
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=20121120080805.GU10560@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=g.liakhovetski@gmx.de \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@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).