public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: len.brown@intel.com, Greg KH <greg@kroah.com>,
	Pavel Machek <pavel@suse.cz>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-acpi@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	linux-pm@osdl.org
Subject: [RFC] ACPI vs device ordering on resume
Date: Tue, 14 Nov 2006 15:30:26 -0800	[thread overview]
Message-ID: <20061114153026.730deb94@freekitty> (raw)

If I do a suspend-to-ram then resume on a Sony Vaio laptop with sky2 driver,
the first interrupt gets misrouted to the original shared IRQ, rather than
to the MSI irq expected.

During the pci_restore process, the MSI information and the PCI command register 
are restored properly. But later during resume, inside the ACPI evaluation of
the WAK method, the PCI_COMMAND  INTX_DISABLE (0x400) flag is being cleared.
My guess is that the BIOS ends up doing some resetting of devices.

I may be able to workaround the problem for this one device, but it brings up
a more general issue about what the ordering should be during resume. If ACPI
evaluation (which I assume talks to the BIOS), might change device state, it
seems that ACPI code should execute before resuming devices not after. But changing
the order here seems drastic.

An alternate solution would be to have two pm_ops, one for early_resume
and another for late, and split the ACPI work.

--- 2.6.19-rc5.orig/kernel/power/main.c	2006-11-14 14:24:37.000000000 -0800
+++ 2.6.19-rc5/kernel/power/main.c	2006-11-14 14:25:23.000000000 -0800
@@ -132,12 +132,12 @@
 
 static void suspend_finish(suspend_state_t state)
 {
+	if (pm_ops && pm_ops->finish)
+		pm_ops->finish(state);
 	device_resume();
 	resume_console();
 	thaw_processes();
 	enable_nonboot_cpus();
-	if (pm_ops && pm_ops->finish)
-		pm_ops->finish(state);
 	pm_restore_console();
 }
 


-- 
Stephen Hemminger <shemminger@osdl.org>

             reply	other threads:[~2006-11-14 23:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-14 23:30 Stephen Hemminger [this message]
2006-11-14 23:59 ` [RFC] ACPI vs device ordering on resume Linus Torvalds
2006-11-15  7:03 ` [linux-pm] " Len Brown
2006-11-15  9:32   ` Rafael J. Wysocki
2006-11-15 16:47   ` Linus Torvalds
2006-12-01  9:33     ` Pavel Machek
2006-12-01 10:33       ` Rafael J. Wysocki
2006-12-01 10:57         ` Pavel Machek
2006-12-01 11:31           ` Rafael J. Wysocki
2006-12-01 16:12       ` Linus Torvalds
2006-12-01 17:45         ` Alexey Starikovskiy
2006-12-01 18:40           ` Stephen Hemminger
2006-12-01 18:42             ` Alexey Starikovskiy
2006-12-01  1:48   ` Stephen Hemminger
2006-12-01 10:25     ` Rafael J. Wysocki

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=20061114153026.730deb94@freekitty \
    --to=shemminger@osdl.org \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@osdl.org \
    --cc=pavel@suse.cz \
    --cc=torvalds@osdl.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