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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox