From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Linus Walleij <linus.walleij@stericsson.com>,
Liam Girdwood <lrg@slimlogic.co.uk>,
linux-kernel@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
Bengt Jonsson <bengt.g.jonsson@stericsson.com>
Subject: Re: [PATCH 2/4] regulator: add ab8500 per-regulator startup delay
Date: Thu, 10 Mar 2011 15:53:41 +0000 [thread overview]
Message-ID: <20110310155341.GA27206@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <AANLkTim5Qw_PQJ234YsNvvmsg7L-RGfTsuMaTHvUmLHK@mail.gmail.com>
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.
next prev parent reply other threads:[~2011-03-10 15:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 13:43 [PATCH 2/4] regulator: add ab8500 per-regulator startup delay Linus Walleij
2011-03-10 13:49 ` Mark Brown
2011-03-10 15:43 ` Linus Walleij
2011-03-10 15:53 ` Mark Brown [this message]
2011-03-11 11:08 ` Linus Walleij
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=20110310155341.GA27206@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=bengt.g.jonsson@stericsson.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
/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