From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: pm list <linux-pm@lists.linux-foundation.org>,
Robert Hancock <hancockr@shaw.ca>,
Linus Torvalds <torvalds@linux-foundation.org>,
"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>
Subject: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Date: Tue, 25 Dec 2007 15:11:40 +0100 [thread overview]
Message-ID: <200712251511.41296.rjw@sisk.pl> (raw)
In-Reply-To: <200712251312.43478.carlos@strangeworlds.co.uk>
On Tuesday, 25 of December 2007, Carlos Corbacho wrote:
> On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote:
> > Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning
> > from the Working to the Sleeping State (which is what we're discussing
> > here):
> >
> > 3. OSPM places all device drivers into their respective Dx state. If the
> > device is enabled for wake, it enters the Dx state associated with the wake
> > capability. If the device is not enabled to wake the system, it enters the
> > D3 state.
> > 4. OSPM executes the _PTS control method, passing an argument that
> > indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2,
> > S3, and S4).
> >
> > My opinion is that we should follow this part of the specification and so
> > we do.
>
> This is that same section from ACPI 1.0B:
>
> 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an
> argument that indicates the desired sleeping state (1, 2, 3, or 4 representing
> S1, S2, S3, and S4).
>
> 4. The OS places all device drivers into their respective Dx state. If the
> device is enabled for wakeup, it enters the Dx state associated with the
> wakeup capability. If the device is not enabled to wakeup the system, it
> enters the D3 state.
>
> The DSDTs in question also claim ACPI 1.0 compatiblity.
>
> > You're wrong, sorry.
>
> No, I'm not entirely wrong - read the 1.0 spec, and read section 7.3.2 of the
> ACPI 2.0 spec.
>
> * ACPI 1.0 is very clear - we are breaking the 1.0 spec
By following the 2.0 and later ones. Well ...
> * ACPI 2.0 is contradictory - section 7.3.2 repeats 1.0 ad verbatim (which is
> what I quote in reply to Robert Hancock), but as you point out, 9.3.2 says
> the opposite.
>
> So, 1.0 and 3.0 are very clear and rather different on this, and 2.0 is
> contradictory (and I presume this is one of the points ACPI 3.0 set out to
> clean up).
>
> I will rescind my point on ACPI 2.0 - I don't know what we should or shouldn't
> be doing there, the spec is unclear.
I think we should follow section 9.3.2 that is explicit and has been reiterated
in the 3.0 specification.
> But for ACPI 1.0, we are doing the wrong thing.
Yes, we are.
OK, I think we can rearrange things to call _PTS early for ACPI 1.0x-compliant
systems.
Thanks,
Rafael
next prev parent reply other threads:[~2007-12-25 13:52 UTC|newest]
Thread overview: 34+ 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 [this message]
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
[not found] <200712231419.40207.carlos@strangeworlds.co.uk>
2007-12-23 16:30 ` x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM Rafael J. Wysocki
2007-12-23 17:57 ` Ingo Molnar
2007-12-23 18:00 ` Linus Torvalds
2007-12-23 22:20 ` Rafael J. Wysocki
2007-12-23 23:12 ` H. Peter Anvin
2007-12-24 0:09 ` Carlos Corbacho
2007-12-24 0:56 ` Linus Torvalds
2007-12-24 1:14 ` Linus Torvalds
2007-12-24 3:05 ` Carlos Corbacho
2007-12-24 13:44 ` Rafael J. Wysocki
2007-12-24 18:34 ` Linus Torvalds
2007-12-24 21:53 ` Carlos Corbacho
2007-12-25 12:12 ` Pavel Machek
2007-12-25 12:28 ` Carlos Corbacho
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=200712251511.41296.rjw@sisk.pl \
--to=rjw@sisk.pl \
--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-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mingo@elte.hu \
--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