[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110310155341.GA27206@opensource.wolfsonmicro.com>
Date: Thu, 10 Mar 2011 15:53:41 +0000
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Linus Walleij <linus.walleij@...ricsson.com>,
Liam Girdwood <lrg@...mlogic.co.uk>,
linux-kernel@...r.kernel.org, Lee Jones <lee.jones@...aro.org>,
Bengt Jonsson <bengt.g.jonsson@...ricsson.com>
Subject: Re: [PATCH 2/4] regulator: add ab8500 per-regulator startup delay
On Thu, Mar 10, 2011 at 04:43:50PM +0100, Linus Walleij wrote:
> On Thu, Mar 10, 2011 at 2:49 PM, Mark Brown
> > You should be implementing the enable_time() operation for the regulator
> > for this.
> I looked into it, but the core implicitly only does delays after
> enable(), and our delays affect disable() and set_voltage()
You should add the appropriate generic operations, then. This is hardly
unique to your hardware and having the information exposed in the driver
ops will allow the core to do helpfult hings with bulk operations.
> as well. disable() may look superfluous but I bet there may be
> cases where not having a voltage fully disabled before doing
> something will cause immesurable harm.
Given how heavily dependant collapsing the voltage is on the external
circuitry I'm not sure the driver can say too much useful here. Usually
you're either going to collapse very quickly due to active discharge and
load or you're heavily dependant on the board.
> I was thinking about extending the present mechanism in
> core by refactoring the signature of the enable_time()
> as such:
Just add separate operations for each query - set_voltage() needs more
information to tell you a number anyway as it'll need to know the target
it's going to be asked about.
--
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