From: frank.hofmann@tomtom.com (Frank Hofmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v5] ARM hibernation / suspend-to-disk (fwd)
Date: Mon, 13 Jun 2011 17:11:07 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.00.1106131643420.19778@localhost6.localdomain6> (raw)
In-Reply-To: <alpine.DEB.2.00.1106131546070.19778@localhost6.localdomain6>
On Mon, 13 Jun 2011, Frank Hofmann wrote:
[ ... ]
> So it's kind of a two-pronged attack to minimize the SoC-specific code,
> Colin's framework to extract common code from the "outer" parts and Russell's
> cpu_suspend/resume to extract common code from the "inner" parts.
Also, to clarify on the hibernation side:
The biggest shortfall of the hibernation support patch that I've posted is
that it currently has no awareness of the "peripheral" side of things at
all, i.e. all the stuff done by the platform_suspend_ops->begin/enter/end
for the suspend-to-mem case isn't replicated sufficiently by the
hibernation codepath.
If you like, swsusp_arch_suspend / resume are on the same level of
complexity as are the functions in platform_suspend_ops. But the current
hibernation patch does only parts of that. It gets away with this largely
because it "resumes from ON" ...
As far as that is concerned, Russell really has a point, to do all this
properly / well for the hibernation case, a hibernation-specific approach
on the platform_ops abstraction level would be better than just to hack
low-level generics together for the sake of hacking low-level generics
together.
If just doing per-SoC hibernation, then the code bloat problem remains, on
ARM there's already platform_suspend_ops per SoC; if one adds a full set
of platform_hibernation_ops per SoC without thinking where/how to
consolidate, it'd only create another mess. Beware the beginnings ...
I had thought the idea of using cpu_suspend / resume actually made it
clear that my main point for all this "use generics wherever imaginable"
is to never allow for unnecessary bloat in the first place and hence opt
for generics even if somewhat imperfect / shoehorned for the general case.
I'd like to apologize if that didn't come over.
I'm following the work in this area; compared to where things were a year
ago a lot of things have happened already. In a way, my hope is that part
of all this blah of mine is helping to identify areas where code might be
shared even if that starts out as coincidental (as is the current use of
cpu_suspend / resume inside the hibernation patch).
FrankH.
next prev parent reply other threads:[~2011-06-13 16:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-13 12:04 [RFC PATCH v5] ARM hibernation / suspend-to-disk (fwd) Frank Hofmann
2011-06-13 12:26 ` Russell King - ARM Linux
2011-06-13 12:40 ` Frank Hofmann
2011-06-13 13:20 ` Frank Hofmann
2011-06-13 13:56 ` Dave Martin
2011-06-13 15:34 ` Frank Hofmann
2011-06-13 16:11 ` Frank Hofmann [this message]
2011-06-13 16:44 ` Russell King - ARM Linux
2011-06-15 13:35 ` Frank Hofmann
2011-06-16 21:31 ` Russell King - ARM Linux
2011-06-20 12:32 ` Frank Hofmann
2011-06-21 14:35 ` Russell King - ARM Linux
2011-06-29 14:52 ` Matthieu CASTET
2011-06-29 15:14 ` Frank Hofmann
2011-06-29 20:08 ` Will Deacon
2011-07-05 12:37 ` Matthieu CASTET
[not found] ` <2C577202CB5719438D4E9608C565CB2C01B69D7F@NL-EXC-07.intra.local>
2011-07-05 17:09 ` Matthieu CASTET
2011-09-30 7:48 ` Barry Song
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=alpine.DEB.2.00.1106131643420.19778@localhost6.localdomain6 \
--to=frank.hofmann@tomtom.com \
--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