linux-kernel - Re: [PATCH v6 0/7] This is the 1st version of suspend for RK3288.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=U-HesWSHdtiNq=5KquuBUR5_EBrL=rfZsAZEn+uuU5gw@mail.gmail.com>
Date:	Wed, 29 Oct 2014 15:26:21 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Heiko Stübner <heiko@...ech.de>
Cc:	Kevin Hilman <khilman@...nel.org>,
	Chris Zhong <zyw@...k-chips.com>,
	Mike Turquette <mturquette@...aro.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Russell King <linux@....linux.org.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	linux-gpio@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kumar Gala <galak@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Tony Xie <xxx@...k-chips.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v6 0/7] This is the 1st version of suspend for RK3288.

Heiko,

On Wed, Oct 29, 2014 at 2:50 PM, Heiko Stübner <heiko@...ech.de> wrote:
> Am Mittwoch, 29. Oktober 2014, 13:06:05 schrieb Kevin Hilman:
>> Hi Chris,
>>
>> Chris Zhong <zyw@...k-chips.com> writes:
>> > RK3288 can shut down the cpu, gpu and other device controllers in suspend,
>> > and it will pull the GLOBAL_PWROFF pin to high in the final stage of the
>> > process of suspend, pull the pin to low again when resume.
>>
>> I tried to test this on top of linux-next (next-20141029) and it doesn't
>> wake up from serial port activity.
>>
>> Can you describe how to test this, as well as describe dependencies on
>> other out-of-tree patches, including pointers to where they've been
>> posted.
>>
>> Also, please describe how you tested this and on which hardware
>> platforms.  It's a big help to reviewers to know how it's been tested,
>> and for anyone with similar hardware to know what else it's been tested
>> on.
>
> When testing this series it did go to sleep with
>
> / # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.010 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.010 seconds) done.
> PM: suspend of devices complete after 0.001 msecs
> PM: late suspend of devices complete after 0.001 msecs
> PM: noirq suspend of devices complete after 0.001 msecs
> Disabling non-boot CPUs ...
> CPU1: shutdown
> CPU2: shutdown
> CPU3: shutdown
>
> and the change in pmic-noise lets me assume it's really asleep.
>
>
> But I'm not exactly sure how to wake it up again. I even hard-wired the gpio-
> keys to always enable the irq wake, but so far it didn't wake again when
> pressing the power-key on the evb.
>
> If anyone wants to peek, the collected patches (Doug's and Chris') can be
> found on [0].

Unless you get a device tree that sets up regulator states I think
you're going to be SOL.  In other words one thing that will definitely
bite you is (7592100 ARM: dts: add suspend voltage setting for RK808).

That's referencing the "global_pwroff" which means we'll be telling
the PMIC when we suspend.  That's good but the PMIC hasn't been
programmed with any reasonable voltages because all the device tree
properties are ignored.  That's not good.  You can see my comments
about this at <https://patchwork.kernel.org/patch/5186951/>

Also: I think that I remember the GPU being pretty unhappy if you
turned its voltage off but didn't gate its power domain.  At the
moment I've got all the power domain patches sitting in my tree plus
<https://chromium-review.googlesource.com/#/c/223464/>.  You might
also just be able to change the GPU not to be powered off in suspend
(but then you need to program a good voltage to it).


At the moment all of my testing is happening in the chromeos-3.14 tree
(which has a ton of backports and thus isn't that different than
mainline as far as Rockchip is concerned).  You could theoretically
try jamming Chris's stuff into the top of the chromeos-3.14 tree and
see what happens on EVB.  I may be able to give that a shot
tomorrow...

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