From: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Question about fixed regulator DT properties
Date: Wed, 26 Nov 2014 21:57:33 +0200 [thread overview]
Message-ID: <547630AD.1010108@mentor.com> (raw)
In-Reply-To: <20141126192021.GU7712-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 26.11.2014 21:20, Mark Brown wrote:
> On Wed, Nov 26, 2014 at 09:13:50PM +0200, Vladimir Zapolskiy wrote:
>
>> If I want to enable a fixed regulator (not controlled by
>> bootloader/firmware) by Linux on boot or when fixed.ko module is bound,
>> shall I specify the same "regulator-boot-on" property? At least this is
>> the practical way to enable a fixed and/or gpio regulator right now, but
>> is it correct?
>
> It depends what you're trying to accomplish by doing this.
If "regulator-boot-on" is specified and the regulator is enabled by
bootloader/firmware, then the kernel re-enables it.
If "regulator-boot-on" is specified and the regulator is untouched by
bootloader/firmware, then the kernel simply enables it.
As far as I understand the latter side-effect is exploited on quite many
ARM boards, when there is no defined regulator consumer, but I agree
that it looks hackish. My assumption is that probably fixed regulator
logic around "regulator-boot-on" property should be changed, so that the
kernel will not attempt to physically re-enable/enable the
"regulator-boot-on" regulator at all, then misusage of the property
should gone forced by necessity of finding a proper regulator consumer.
>> Or should the regulator always be enabled externally (assuming
>> "regulator-always-on" is omitted) after registration independently on
>> "regulator-boot-on" property?
>
> Best practice is that there should be a consumer which keeps the
> regulator enabled whenever it is required. There should normally be
> little use for boot-on, it's mostly there to ease handover from the
> bootloader in cases where we can't read the hardware state - if you're
> not sure if you should use it the chances are you shouldn't.
>
Right, thank you for explanation.
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: Question about fixed regulator DT properties
Date: Wed, 26 Nov 2014 21:57:33 +0200 [thread overview]
Message-ID: <547630AD.1010108@mentor.com> (raw)
In-Reply-To: <20141126192021.GU7712@sirena.org.uk>
On 26.11.2014 21:20, Mark Brown wrote:
> On Wed, Nov 26, 2014 at 09:13:50PM +0200, Vladimir Zapolskiy wrote:
>
>> If I want to enable a fixed regulator (not controlled by
>> bootloader/firmware) by Linux on boot or when fixed.ko module is bound,
>> shall I specify the same "regulator-boot-on" property? At least this is
>> the practical way to enable a fixed and/or gpio regulator right now, but
>> is it correct?
>
> It depends what you're trying to accomplish by doing this.
If "regulator-boot-on" is specified and the regulator is enabled by
bootloader/firmware, then the kernel re-enables it.
If "regulator-boot-on" is specified and the regulator is untouched by
bootloader/firmware, then the kernel simply enables it.
As far as I understand the latter side-effect is exploited on quite many
ARM boards, when there is no defined regulator consumer, but I agree
that it looks hackish. My assumption is that probably fixed regulator
logic around "regulator-boot-on" property should be changed, so that the
kernel will not attempt to physically re-enable/enable the
"regulator-boot-on" regulator at all, then misusage of the property
should gone forced by necessity of finding a proper regulator consumer.
>> Or should the regulator always be enabled externally (assuming
>> "regulator-always-on" is omitted) after registration independently on
>> "regulator-boot-on" property?
>
> Best practice is that there should be a consumer which keeps the
> regulator enabled whenever it is required. There should normally be
> little use for boot-on, it's mostly there to ease handover from the
> bootloader in cases where we can't read the hardware state - if you're
> not sure if you should use it the chances are you shouldn't.
>
Right, thank you for explanation.
--
With best wishes,
Vladimir
next prev parent reply other threads:[~2014-11-26 19:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 15:00 Question about Vladimir Zapolskiy
2014-11-18 15:00 ` Vladimir Zapolskiy
2014-11-19 14:38 ` Question about fixed regulator DT properties Vladimir Zapolskiy
2014-11-19 14:38 ` Vladimir Zapolskiy
[not found] ` <546CAB49.8030103-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2014-11-25 12:17 ` Mark Brown
2014-11-25 12:17 ` Mark Brown
[not found] ` <20141125121749.GV7712-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-11-26 17:27 ` Vladimir Zapolskiy
2014-11-26 17:27 ` Vladimir Zapolskiy
2014-11-26 17:53 ` Mark Brown
[not found] ` <20141126175304.GM7712-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-11-26 19:13 ` Vladimir Zapolskiy
2014-11-26 19:13 ` Vladimir Zapolskiy
[not found] ` <5476266E.9040901-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2014-11-26 19:20 ` Mark Brown
2014-11-26 19:20 ` Mark Brown
[not found] ` <20141126192021.GU7712-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-11-26 19:57 ` Vladimir Zapolskiy [this message]
2014-11-26 19:57 ` Vladimir Zapolskiy
2014-11-26 20:36 ` Mark Brown
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=547630AD.1010108@mentor.com \
--to=vladimir_zapolskiy-nmggyn9qbj3qt0dzr+alfa@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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.