linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: how to enable suspend to ram for arm-64 bits
Date: Wed, 19 Oct 2016 11:42:27 +0200	[thread overview]
Message-ID: <20161019094227.GB1461@amd> (raw)
In-Reply-To: <20161018104539.GB15639@leverpostej>

On Tue 2016-10-18 11:45:39, Mark Rutland wrote:
> On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> > > >b. in arm64, if some platform has its own suspend flow,  couldn't it
> > > >adopts arm/match-xxx to register its own global suspend method?
> > > 
> > > No, PSCI is highly recommended.
> > 
> > Relying on firmware for suspend on x86 was a great disaster, lets not repeat
> > that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
> > for example) -- feel free to copy that code from arm32.
> 
> Quite frankly, copying hundreds of lines of board-specific code
> (including assembly that won't compile) is unlikely to help.
> 
> So far arm64 requires well-defined, standard, reusable interfaces (e.g.
> PSCI). That cleanly separates concerns (e.g. anyone can implement the
> backend without mandatory changes to the kernel), and keeps things
> maintainable.

Either the lowlevel suspend code is stable and bug free, and then
having that code is not a problem. Or the lowlevel suspend code is
complex enough to contain some bugs, and in such case it is better to
debug and update it with kernel.

> ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
> can use and build atop of. It's open source (three-clause BSD with DCO),
> and accepts board ports. You can have a completely open stack,
> regardless of whether part of that stack is firmware.

If something is called "Trusted", it is not trustworthy.

BSD is better than closed source, but it also means that you will not
get the sources from your hw vendor.

Being separate module means it will be never updated.

Being separate module means it will be hard to debug, in area where
debugging is already pretty hard.

Can it do advanced stuff like deep powersaving on N900 idle?

Just don't do it.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/05d8de63/attachment.sig>

  parent reply	other threads:[~2016-10-19  9:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17 17:26 how to enable suspend to ram for arm-64 bits yoma sophian
2016-08-17 17:49 ` Sudeep Holla
2016-08-18  2:07   ` yoma sophian
2016-08-18  8:47     ` Sudeep Holla
2016-08-18 10:43       ` yoma sophian
2016-08-18 10:52         ` Sudeep Holla
2016-08-22 14:41           ` yoma sophian
2016-08-22 15:00             ` Sudeep Holla
2016-10-18 10:00       ` Pavel Machek
2016-10-18 10:21         ` Sudeep Holla
2016-10-18 10:28         ` Lorenzo Pieralisi
2016-10-18 10:45         ` Mark Rutland
2016-10-18 10:59           ` Sudeep Holla
2016-10-19  7:18             ` yoma sophian
2016-10-19  9:42           ` Pavel Machek [this message]
2016-10-19 13:11             ` Mark Rutland
2016-11-03  9:57               ` Pavel Machek

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=20161019094227.GB1461@amd \
    --to=pavel@ucw.cz \
    --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).