Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1214807 > unrolled thread

Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties

Started byDoug Anderson <dianders@chromium.org>
First post2015-08-27 21:40 +0200
Last post2015-08-27 23:00 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties Doug Anderson <dianders@chromium.org> - 2015-08-27 21:40 +0200
    Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties Brian Norris <briannorris@chromium.org> - 2015-08-27 23:00 +0200
    Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties Heiko Stuebner <heiko@sntech.de> - 2015-08-27 23:00 +0200

#1214807 — Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties

FromDoug Anderson <dianders@chromium.org>
Date2015-08-27 21:40 +0200
SubjectRe: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties
Message-ID<q2bbI-5yj-17@gated-at.bofh.it>
Hi,

On Tue, Aug 18, 2015 at 11:19 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> great, just take into account the deep vs. shallow suspend modes :-)

One note: do you think it would make sense to re-implement shallow
suspend as "standby"?  I had a proof of concept doing that in
<https://chromium-review.googlesource.com/#/c/275123/>.  One nice
advantage is that you "magically" get a second set of regulator states
for standby vs "mem".

If I understand correctly, the distinction between "standby" and "mem"
is not too clearly defined, so if we wanted to use it for this it
wouldn't be terrible?

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1214823

FromBrian Norris <briannorris@chromium.org>
Date2015-08-27 23:00 +0200
Message-ID<q2cr9-7g7-13@gated-at.bofh.it>
In reply to#1214807
On Thu, Aug 27, 2015 at 10:51:22PM +0200, Heiko Stuebner wrote:
> Am Donnerstag, 27. August 2015, 12:30:51 schrieb Doug Anderson:
> > If I understand correctly, the distinction between "standby" and "mem"
> > is not too clearly defined, so if we wanted to use it for this it
> > wouldn't be terrible?

I never understood many clear definitions here either, personally.

> From reading Documentation/power/states.txt it looks like the boot-cpu is 
> supposed to retain power in the suspend state. Although we also do not lose 
> "operating state" in our suspend I guess?
> 
> So using the shallow suspend as standby sounds interesting, for the time when 
> the deep suspend works too. If there is only one suspend state it 
> automatically becomes the "mem"-state it seems.

It's not really "automatic", it's a product of this line:

static const struct platform_suspend_ops rk3288_suspend_ops = {
        .enter   = rk3288_suspend_enter,
        .valid   = suspend_valid_only_mem,  <--- here
        .prepare = rk3288_suspend_prepare,
        .finish  = rk3288_suspend_finish,
};

and the fact that we don't check the 'state' argument in
.enter/.prepare/.finish.

But still, I'm not sure it's productive to rename shallow until we support
deep.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1214825

FromHeiko Stuebner <heiko@sntech.de>
Date2015-08-27 23:00 +0200
Message-ID<q2cr9-7g7-15@gated-at.bofh.it>
In reply to#1214807
Am Donnerstag, 27. August 2015, 12:30:51 schrieb Doug Anderson:
> Hi,
> 
> On Tue, Aug 18, 2015 at 11:19 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> > great, just take into account the deep vs. shallow suspend modes :-)
> 
> One note: do you think it would make sense to re-implement shallow
> suspend as "standby"?  I had a proof of concept doing that in
> <https://chromium-review.googlesource.com/#/c/275123/>.  One nice
> advantage is that you "magically" get a second set of regulator states
> for standby vs "mem".

Somewhere I've read something about keeping wifi associated to an ap during 
suspend which might be a candidate for such a distinction?


> If I understand correctly, the distinction between "standby" and "mem"
> is not too clearly defined, so if we wanted to use it for this it
> wouldn't be terrible?

From reading Documentation/power/states.txt it looks like the boot-cpu is 
supposed to retain power in the suspend state. Although we also do not lose 
"operating state" in our suspend I guess?

So using the shallow suspend as standby sounds interesting, for the time when 
the deep suspend works too. If there is only one suspend state it 
automatically becomes the "mem"-state it seems.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web