All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: Len Brown <lenb@kernel.org>
Cc: len.brown@intel.com, linux-pm@lists.osdl.org,
	Greg KH <greg@kroah.com>, Pavel Machek <pavel@suse.cz>,
	Andrew Morton <akpm@osdl.org>,
	linux-acpi@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	linux-pm@osdl.org
Subject: Re: [linux-pm] [RFC] ACPI vs device ordering on resume
Date: Thu, 30 Nov 2006 17:48:25 -0800	[thread overview]
Message-ID: <20061130174825.7608c33b@localhost.localdomain> (raw)
In-Reply-To: <200611150203.30965.len.brown@intel.com>

On Wed, 15 Nov 2006 02:03:30 -0500
Len Brown <len.brown@intel.com> wrote:

> On Tuesday 14 November 2006 18:30, Stephen Hemminger wrote:
> > 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();
> >  }
> 
> Yes, I agree that _WAK needs to come before device_resume().
> Need to let any BIOS nasties happen and get over with before we restore device drivers.
> This is consistent with the wording in ACPI 3.0b (section 7.4) that says
> 11. _WAK is run
> 12. OSPM notifies all native device drivefrs of the return from the sleep state transition
> 
> However, commit 1a38416cea8ac801ae8f261074721f35317613dc says that
> _WAK must follow INIT -- ie finish() must come after enable_nonboot_cpus(),
> and this patch as it stands would violate that.
> 
> So it looks like we need this sequence:
> 
> enable_nonboot_cpus() /* INIT */
> finish()	/* _WAK */
> device_resume()
> 

Do you want to do this, or shall I? send off a patch.
I can test on about 5 machines first.

  parent reply	other threads:[~2006-12-01  1:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-14 23:30 [RFC] ACPI vs device ordering on resume Stephen Hemminger
2006-11-14 23:59 ` 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 [this message]
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=20061130174825.7608c33b@localhost.localdomain \
    --to=shemminger@osdl.org \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=len.brown@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@lists.osdl.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 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.