mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Patrick Mochel <mochel@osdl.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	Linus Torvalds <torvalds@transmeta.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	ACPI mailing list <acpi-devel@lists.sourceforge.net>
Subject: Re: [ACPI] Re: Fixes to suspend-to-RAM
Date: 19 Feb 2003 00:08:21 +0100	[thread overview]
Message-ID: <1045609701.7399.5.camel@zion.wanadoo.fr> (raw)
In-Reply-To: <Pine.LNX.4.33.0302181535520.1035-100000@localhost.localdomain>

On Tue, 2003-02-18 at 22:41, Patrick Mochel wrote:

> I propose that we don't even call SUSPEND_DISABLE. Based on recent
> conversations, it appears that we can and should do the entire device
> suspend sequence in two passes - SUSPEND_SAVE_STATE with interrupts
> enabled, and SUSPEND_POWER_DOWN with interrupts disabled.

Right... though I still care about my early pet SUSPEND_NOTIFY for
the few things that need to care about allocations issues (that is
that need to know they can no longer rely on GFP_KERNEL & friends
not blocking until wakeup).

Regarding failure, what I did with success on pmac (I had occasional
failure to suspend from the OHCI controller or video drivers during
tests, though those seem to be quite rare in real life) is to call
back the wakeup calls for devices that got the matching suspend
call.

I beleive it's as safe to just call all wakeup calls in order
instead though, and it makes things simpler (as the individual
drivers should really know in what state they really are).

Ben.


      parent reply	other threads:[~2003-02-18 22:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-18 21:17 Pavel Machek
2003-02-18 21:14 ` Patrick Mochel
2003-02-18 21:43   ` Pavel Machek
2003-02-18 21:41     ` Patrick Mochel
2003-02-18 22:07       ` Pavel Machek
2003-02-18 22:00         ` Patrick Mochel
2003-02-18 22:31           ` Pavel Machek
2003-02-18 23:08       ` Benjamin Herrenschmidt [this message]

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=1045609701.7399.5.camel@zion.wanadoo.fr \
    --to=benh@kernel.crashing.org \
    --cc=acpi-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@transmeta.com \
    /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

all inboxes | Powered by JetHome®