All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank.Hofmann@tomtom.com (Frank Hofmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-pm] [RFC PATCH] ARM hibernation / suspend-to-disk support code
Date: Sun, 22 May 2011 09:01:14 +0200	[thread overview]
Message-ID: <2C577202CB5719438D4E9608C565CB2C01B69D7B@NL-EXC-07.intra.local> (raw)
In-Reply-To: 201105210027.17159.rjw@sisk.pl

> [ ... ]
> > > r8_FIQ..r12_FIQ can store arbitrary state used by the FIQ handler,
> > > if FIQ is in use.  Can we expect any driver using FIQ to save/restore
> > > this state itself, rather than doing it globally?  This may be
> > > reasonable.
> > 
> > We don't need to save/restore those, because at the time the snapshot is 
> > taken interrupts are off and we cannot be in any trap handler either. On 
> > resume, the kernel that has been loaded has initialized them properly 
> > already.
> 
> I'm not sure if this is a safe assumption in general.  We may decide to
> switch to loading hibernate images from boot loaders, for example, and
> it may not hold any more.  Generally, please don't assume _anything_ has
> been properly initialized during resume, before the image is loaded.
> This has already beaten us a couple of times.
> 
> Thanks,
> Rafael

Hi Rafael,

regarding "cannot rely on any state", if that is so then it seems quite unnecessary to save/restore _any_ ARM non-#SYSTEM_MODE state - it'd better be reinitialized by calling cpu_init() after the "core restore" callback. The archives were quite a bit helpful in this context:

http://www.mail-archive.com/linux-omap at vger.kernel.org/msg12671.html

that's the same situation isn't it ?

Regarding FIQ: I agree with Russell and others who previously stated that a driver using FIQ is responsible for implementing suspend/resume hooks itself. But what could be done is to disable/enable it for the snapshot, just in case.

I've also found out that the vmlinux.lds changes don't seem to be necessary - they've been the last remnant of the "old" ARM hibernation patch, but just leaving those out looks to make no difference (the nosave data still ends up in the same place, with the same elf section attributes).

With all this in mind, the core part of the patch becomes somewhat simpler. See attached.


I'll test this on Monday.
FrankH.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110522/71096fef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hibernation-core-22May2011.patch
Type: text/x-patch
Size: 5391 bytes
Desc: hibernation-core-22May2011.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110522/71096fef/attachment.bin>

  reply	other threads:[~2011-05-22  7:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3DCE2F529B282E4B8F53D4D8AA406A07014FFE@008-AM1MPN1-022.mgdnok.nokia.com>
2011-05-19 17:31 ` [RFC PATCH] ARM hibernation / suspend-to-disk support code Frank Hofmann
2011-05-20 11:37   ` Dave Martin
2011-05-20 11:37   ` Dave Martin
2011-05-20 12:39     ` Frank Hofmann
2011-05-20 12:39       ` Frank Hofmann
2011-05-20 15:03       ` Dave Martin
2011-05-20 15:03       ` Dave Martin
2011-05-20 16:24         ` Frank Hofmann
2011-05-23  9:42           ` Dave Martin
2011-05-23  9:42           ` Dave Martin
2011-05-20 16:24         ` Frank Hofmann
2011-05-20 17:53         ` Nicolas Pitre
2011-05-20 17:53         ` Nicolas Pitre
2011-05-20 18:07       ` Russell King - ARM Linux
2011-05-20 18:07       ` Russell King - ARM Linux
2011-05-22  6:39         ` Frank Hofmann
2011-05-20 22:27       ` [linux-pm] " Rafael J. Wysocki
2011-05-22  7:01         ` Frank Hofmann [this message]
2011-05-22  9:54           ` Rafael J. Wysocki
2011-05-22  9:54           ` Rafael J. Wysocki
2011-05-22  7:01         ` Frank Hofmann
2011-05-23  9:52         ` Dave Martin
2011-05-23  9:52         ` [linux-pm] " Dave Martin
2011-05-23 13:37           ` Frank Hofmann
2011-05-23 14:32             ` Russell King - ARM Linux
2011-05-23 14:32               ` [linux-pm] " Russell King - ARM Linux
2011-05-23 15:57               ` [RFC PATCH v2] " Frank Hofmann
2011-05-23 15:57               ` Frank Hofmann
2011-05-23 13:37           ` [RFC PATCH] " Frank Hofmann
2011-05-20 22:27       ` Rafael J. Wysocki
2011-05-20 18:05     ` Russell King - ARM Linux
2011-05-20 18:05     ` Russell King - ARM Linux
2011-05-23 10:01       ` Dave Martin
2011-05-23 10:12         ` Russell King - ARM Linux
2011-05-23 10:12         ` Russell King - ARM Linux
2011-05-23 11:16           ` Dave Martin
2011-05-23 16:11             ` Russell King - ARM Linux
2011-05-23 16:38               ` Dave Martin
2011-05-24 12:33                 ` Frank Hofmann
2011-05-24 12:33                 ` Frank Hofmann
2011-05-23 16:38               ` Dave Martin
2011-05-23 16:11             ` Russell King - ARM Linux
2011-05-23 11:16           ` Dave Martin
2011-05-23 10:01       ` Dave Martin
2011-05-24 13:27     ` [RFC] ARM hibernation, cpu-type-specific code Frank Hofmann
2011-05-19 17:31 ` [RFC PATCH] ARM hibernation / suspend-to-disk support code Frank Hofmann

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=2C577202CB5719438D4E9608C565CB2C01B69D7B@NL-EXC-07.intra.local \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.