public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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