From: Ulf Hansson <ulf.hansson@stericsson.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mattias WALLIN <mattias.wallin@stericsson.com>,
Jonas ABERG <jonas.aberg@stericsson.com>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH] regulator: core: Keep boot_on regulators powered during init
Date: Mon, 23 Apr 2012 14:21:49 +0200 [thread overview]
Message-ID: <4F95495D.4050508@stericsson.com> (raw)
In-Reply-To: <20120423110522.GB8318@opensource.wolfsonmicro.com>
On 04/23/2012 01:05 PM, Mark Brown wrote:
> On Mon, Apr 23, 2012 at 12:52:05PM +0200, Ulf Hansson wrote:
>
>> I realize that using boot_on, which has been around for quite some
>> time could have problems. If not using the existing boot_on
>> constraint, do you have an idea of how to accomplish what I want?
>> Should I invent a new constraint option to be used in
>> regulator_init_complete!?
>
> To be honest I don't entirely understand what your goal is at the system
> level - the current idea is that either the regulator will be marked as
> always_on or it should be enabled by a consumer. What is the scenario
> in which neither of these is sufficient?
The consumer do not want to enable the regulator directly from its
device probe routine, it is handled through a scheduled work.
Moreover the regulator shall not be switched off unless the consumer
work decides that this is OK.
So, we actually will have a race were the work _might_ be able to
preventing the late_init_call (regulator_init_complete) from disabling
the regulator if has reached the point were it has enabled the regulator.
Hopes this clarifies the background a bit more.
Kind regards
Ulf Hansson
next prev parent reply other threads:[~2012-04-23 12:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 9:37 [PATCH] regulator: core: Keep boot_on regulators powered during init Ulf Hansson
2012-04-23 10:18 ` Mark Brown
2012-04-23 10:52 ` Ulf Hansson
2012-04-23 11:05 ` Mark Brown
2012-04-23 12:21 ` Ulf Hansson [this message]
2012-04-23 12:25 ` Mark Brown
2012-04-23 12:45 ` Ulf Hansson
2012-04-23 18:01 ` Mark Brown
2012-04-24 8:09 ` Ulf Hansson
2012-04-24 10:56 ` Mark Brown
2012-04-24 12:43 ` Ulf Hansson
2012-04-25 8:02 ` Mark Brown
2012-04-25 9:37 ` Ulf Hansson
2012-04-25 9:58 ` Mark Brown
2012-04-25 16:45 ` Jassi Brar
2012-04-25 15:34 ` Jassi Brar
2012-04-25 15:44 ` Ulf Hansson
2012-04-25 16:31 ` Jassi Brar
2012-04-26 8:35 ` Mark Brown
2012-04-26 9:10 ` Jassi Brar
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=4F95495D.4050508@stericsson.com \
--to=ulf.hansson@stericsson.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=jonas.aberg@stericsson.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=mattias.wallin@stericsson.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.