mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shaohua Li <shaohua.li@intel.com>
To: Robert Hancock <hancockr@shaw.ca>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Carlos Corbacho <carlos@strangeworlds.co.uk>,
	"H. Peter Anvin" <hpa@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Greg KH <gregkh@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	pm list <linux-pm@lists.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: Suspend code ordering (again)
Date: Tue, 08 Jan 2008 11:03:14 +0800	[thread overview]
Message-ID: <1199761394.28914.1.camel@sli10-desk.sh.intel.com> (raw)
In-Reply-To: <47744291.30100@shaw.ca>

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]


On Fri, 2007-12-28 at 08:25 +0800, Robert Hancock wrote:
> Rafael J. Wysocki wrote: 
> >> Also, as was pointed out, pre-Vista versions of Windows follow ACPI
> 1.0 
> >> and Vista follows 3.0, so 2.0 doesn't really matter since BIOS
> people 
> >> won't test against it. 1.0 specifies that _PTS is to be called
> before 
> >> suspending devices and 3.0 says that the AML must not depend on
> any 
> >> specific device power state, so in both cases it should be safe to
> call 
> >> _PTS before suspending, no? 
> > 
> > Well, IMO, if we take one option only (whichever that is) and there
> are systems 
> > that follow the other one, they will likely break. 
> > 
> > Apart from this, there are BIOSes that openly claim ACPI 2.0 support
> (for 
> > example, the one in my HP nx6325 does that) and they may actually
> prefer the 
> > post-ACPI-1.0 ordering even if they work with the pre-ACPI-2.0 one.
> 
> I doubt they would prefer the later ordering in any way that matters,
> if 
> the Windows version they were designed for uses the earlier ordering.
> 
> It would be best if somebody could manage to find out what ordering 
> Windows XP (and Windows Vista, for good measure) actually use, then
> we 
> could just use that. Virtual machine trickery might be an option -
> the 
> only complication being that it'll be using the DSDT for the fake 
> machine and not the real one..
I modified Qemu and use it to observe how winxp does suspend/resume. So
far, I just get some data for s4 suspend. I did have some interesting
finding.

1. xp seems not save pci config space. Or it appears just save config
PCICMD.
2. the order winxp does looks like
	a. save config (PCICMD), put device to D3 (it appears only for ne2000
NIC)
	b. _PTS
	c. write mem to disk
	d. write ACPI PM1_control register, then system shutdown
3. xp write ACPI GBL_EN bit just after _PTS (for both S4/S5), don't know
why

Attached is the log winxp does s4 suspend, it only includes pci config
read/write and ACPI register read/write.

I managed to make xp enter S3, but fails, so can't get the data for S3
so far. Anybody has other ideas which need to verify winxp, pls let me
know.

Thanks,
Shaohua

[-- Attachment #2: xplog --]
[-- Type: text/plain, Size: 2050 bytes --]

PCI NE2000 read addr 4, val 7
PCI NE2000 read addr 50, val 1
PCI NE2000 read addr 52, val c9c2
PCI NE2000 read addr 54, val 8000
PCI NE2000 write addr 54, val 8003
PCI NE2000 read addr 54, val 8003
PCI NE2000 read addr 4, val 7
PCI NE2000 write addr 4, val 0
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 0, val 71138086
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 64, val 8000000
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 0, val 71138086
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 64, val 8000000
PCI Cirrus VGA read addr 4, val 7
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PIIX3 IDE read addr 4, val 7
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 0, val 71138086
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 5c, val 90000000
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 0, val 71138086
PCI PIIX3 read addr 0, val 70008086
PCI PIIX3 read addr 4, val 7
PCI PIIX3 read addr 8, val 6010000
PCI PIIX3 read addr c, val 800000
PCI PM read addr 5c, val 90000000
ACPI: DBG: 0x00000002
PM readw port=0x0002 val=0xb002
PM writew port=0x0002 val=0x0020
PM readw port=0x0002 val=0xb002
PM readw port=0x0004 val=0xb004
PM readw port=0x0004 val=0xb004
PM writew port=0x0004 val=0x2801
type 2

  parent reply	other threads:[~2008-01-08  3:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.Tr7qmPdet0rF2FSRX/94s2UEMSE@ifi.uio.no>
     [not found] ` <fa.n/XQFa64Zg8snHoyB/rrKzCvAL0@ifi.uio.no>
2007-12-24 16:59   ` [Bug 9528] x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM Robert Hancock
     [not found] ` <fa.5MPS0t6OtOOALbc90ywKDrtik+4@ifi.uio.no>
     [not found]   ` <fa.zg2cR0292Evub+o7LgQUdg4A7ZM@ifi.uio.no>
     [not found]     ` <fa.ZBHAMdWAEaW7Flaz8/Gc8PLZUNg@ifi.uio.no>
2007-12-24 22:40       ` Robert Hancock
2007-12-25  0:03         ` Carlos Corbacho
2007-12-25  2:41           ` ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM) Carlos Corbacho
2007-12-25 13:36             ` Rafael J. Wysocki
2007-12-25 14:07               ` Rafael J. Wysocki
2007-12-25 13:52                 ` Carlos Corbacho
2007-12-25 13:26           ` x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM Rafael J. Wysocki
2007-12-25 13:12             ` Carlos Corbacho
2007-12-25 14:11               ` Rafael J. Wysocki
2007-12-25 17:17               ` Robert Hancock
2007-12-25 18:26                 ` Rafael J. Wysocki
2007-12-26  4:29                   ` Linus Torvalds
2007-12-26  5:13                     ` Robert Hancock
2007-12-26  7:23                     ` Avi Kivity
     [not found] ` <fa.WvaVh83zJOh/eZUrjQOZy4J8JFk@ifi.uio.no>
     [not found]   ` <fa.VsyhBr+FAHB0bTb9poSZS80xN/0@ifi.uio.no>
     [not found]     ` <fa.XycBwhGuyvtVl/QW5HONqLwOags@ifi.uio.no>
2007-12-27 18:07       ` Suspend code ordering (again) Robert Hancock
2007-12-27 20:00         ` Rafael J. Wysocki
2007-12-28  0:25           ` Robert Hancock
2007-12-28  5:41             ` Linus Torvalds
2008-01-08  3:03             ` Shaohua Li [this message]
     [not found] <200712231419.40207.carlos@strangeworlds.co.uk>
2007-12-25 16:13 ` Suspend code ordering (again) (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM) Rafael J. Wysocki
2007-12-26  4:11   ` Linus Torvalds
2007-12-26 15:07     ` Rafael J. Wysocki
2007-12-26 15:24       ` Suspend code ordering (again) Alexey Starikovskiy
2007-12-26 17:50         ` H. Peter Anvin

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=1199761394.28914.1.camel@sli10-desk.sh.intel.com \
    --to=shaohua.li@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=carlos@strangeworlds.co.uk \
    --cc=gregkh@suse.de \
    --cc=hancockr@shaw.ca \
    --cc=hpa@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®