[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.1211200921190.21420@axis700.grange>
Date: Tue, 20 Nov 2012 09:23:41 +0100 (CET)
From: Guennadi Liakhovetski <g.liakhovetski@....de>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
cc: Laxman Dewangan <ldewangan@...dia.com>, lrg@...com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: max8973: add regulator driver support
On Tue, 20 Nov 2012, Mark Brown wrote:
> 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.
Ok, I see, but other my comments still hold.
> > > > > 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.
Understand.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists