Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.

  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