linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties
Date: Wed, 19 Aug 2015 08:19:47 +0200	[thread overview]
Message-ID: <10828643.SSUS2EOuvv@phil> (raw)
In-Reply-To: <20150818232806.GC140911@google.com>

Am Dienstag, 18. August 2015, 16:28:06 schrieb Brian Norris:
> Now that I'm looking a little closer, it seems like other existing DTS's
> are broken too, then. Jerry looks like it was converted to the
> regulator-state-mem node binding, but the conversion doesn't seem to
> make sense when I compare the chromium DTS sources with the for-next
> source I see in your tree.
> 
> In -next:
> 
>      regulators {
>              mic_vcc: LDO_REG2 {
>                         regulator-name = "mic_vcc";
>                         regulator-always-on;
>                         regulator-boot-on;
>                         regulator-min-microvolt = <1800000>;
>                         regulator-max-microvolt = <1800000>;
>                         regulator-state-mem {
>                                 regulator-on-in-suspend;
>                         };
>                 };
>          };
> 
> But chromium had:
> 
>        regulators {
>                 mic_vcc: LDO_REG2 {
>                         regulator-always-on;
>                         regulator-boot-on;
>                         regulator-min-microvolt = <1800000>;
>                         regulator-max-microvolt = <1800000>;
>                         regulator-name = "mic_vcc";
>                         regulator-suspend-mem-disabled;
>                 };
>        };
> 
> So I guess I'll make the proper conversion for all the veyron variants I
> see.

great, just take into account the deep vs. shallow suspend modes :-)

The original regulator-state changes did happen when we had this suspend 
instability (counter and gpioint stuff) and I did go with the values similar to 
the rk3288-evb, as this was the only one resuming at all at the time. So I 
guess I never looked to closesly what it did, as long as the system came out 
of suspend sucessfully again :-)


Heiko

  reply	other threads:[~2015-08-19  6:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 18:44 [PATCH 1/2] ARM: dts: rockchip: add veyron-jaq board Brian Norris
2015-08-18 18:44 ` [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties Brian Norris
2015-08-18 19:17   ` Heiko Stuebner
2015-08-18 20:30     ` Javier Martinez Canillas
2015-08-18 20:38       ` Javier Martinez Canillas
2015-08-18 22:48     ` Brian Norris
2015-08-18 23:28       ` Brian Norris
2015-08-19  6:19         ` Heiko Stuebner [this message]
2015-08-27 19:30           ` Doug Anderson
2015-08-27 20:51             ` Heiko Stuebner
2015-08-27 20:56               ` Brian Norris
2015-08-18 19:19 ` [PATCH 1/2] ARM: dts: rockchip: add veyron-jaq board Heiko Stuebner
2015-08-18 23:01   ` Brian Norris

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=10828643.SSUS2EOuvv@phil \
    --to=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).