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 12:52:05 +0200 [thread overview]
Message-ID: <4F953455.3080002@stericsson.com> (raw)
In-Reply-To: <20120423101804.GA8318@opensource.wolfsonmicro.com>
Hi Mark,
Thanks for a quick reply.
On 04/23/2012 12:18 PM, Mark Brown wrote:
> On Mon, Apr 23, 2012 at 11:37:53AM +0200, Ulf Hansson wrote:
>
>> Regulators which has boot_on constraints set, will now remain
>> powered after regulator_init_complete is done.
>
> This would be a bug. All boot_on means is that the regulator was turned
> on during boot, the regulator is free to vary after that.
The idea is to prevent the late_init_call "regulator_init_complete" from
disabling a regulator that "recently" were enabled due to it's boot_on
constraints.
>
>> In this case we leave the enable->disable operation to be
>> handled by the regulator consumer instead.
>
> Which would be a bug if the consumer wasn't the thing that took the
> reference to the regulator in the first place. Remember, regulators can
> be shared so the consumer can't disable a regulator it didn't enable in
> the first place (unless it used regulator_get_exclusive() but the use
> cases for that are a little suspicious so it'd be worth taking a careful
> look before using it). A consumer can't tell if the regulator was left
> enabled by the firmware on boot or if it has been enabled by another
> consumer.
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!?
Kind regards
Ulf Hansson
next prev parent reply other threads:[~2012-04-23 10:52 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 [this message]
2012-04-23 11:05 ` Mark Brown
2012-04-23 12:21 ` Ulf Hansson
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=4F953455.3080002@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