From: Robert Hancock <hancockr@shaw.ca>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: 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: Thu, 27 Dec 2007 18:25:53 -0600 [thread overview]
Message-ID: <47744291.30100@shaw.ca> (raw)
In-Reply-To: <200712272100.20282.rjw@sisk.pl>
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..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
next prev parent reply other threads:[~2007-12-28 0:26 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 [this message]
2007-12-28 5:41 ` Linus Torvalds
2008-01-08 3:03 ` Shaohua Li
[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=47744291.30100@shaw.ca \
--to=hancockr@shaw.ca \
--cc=akpm@linux-foundation.org \
--cc=carlos@strangeworlds.co.uk \
--cc=gregkh@suse.de \
--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