public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	pm list <linux-pm@lists.linux-foundation.org>
Subject: Re: Why don't we use _TTS method?
Date: Fri, 4 May 2007 00:55:38 +0200	[thread overview]
Message-ID: <200705040055.39007.rjw@sisk.pl> (raw)
In-Reply-To: <20070503222702.GC13426@elf.ucw.cz>

Hi,

On Friday, 4 May 2007 00:27, Pavel Machek wrote:
> Hi!
> 
> > I've got two questions regarding the implementation of the ACPI poweroff/sleep
> > code in drivers/acpi/sleep and drivers/acpi/hardware .
> > 
> > 1) We don't seem to use the _TTS system-control method, although the ACPI
> > specification (ACPI 3.0b) says that this method should be used for intiating
> > and finishing power transitions.  Could you please tell me why we
> > don't use it?
> 
> I guess we simply overlooked that :-(.

Hmm, does it mean we should implement that?

> > 2) In the functions acpi_enter_sleep_state_prep(), acpi_enter_sleep_state(),
> > acpi_leave_sleep_state() we manipulate GPEs quite extensively (we disable
> > and enable them for a couple of times during a transition), although the
> > specification doesn't tell anything about that explicitly.  Could you please
> > explain to me what the purpose of that is?
> 
> We have had some notebooks auto-waking-up just after suspend. Perhaps
> those hacks are workarounds for that problem?

Well, maybe, but if there's anyone who knows *exactly* why we do this and
why it is done in these particular places, I would appreciate it very much if
she or he could explain that to me.

Currently we're having problems with some boxes due to the code reordering that
took place before 2.6.21 and I'm trying to figure out what the source of them
is.  In the process I've observed that the ACPI functions used by us in the
hibernation and suspend code generally don't follow the specification and I'd
like to understand if that's intentional and if so then why.

Also, I'd like to understand why the old code ordering seemed to work better
than the current one, although the current one is closer to what the ACPI spec
says (or so it seems).

Greetings,
Rafael

  reply	other threads:[~2007-05-03 22:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03 20:01 Why don't we use _TTS method? Rafael J. Wysocki
2007-05-03 22:27 ` Pavel Machek
2007-05-03 22:55   ` Rafael J. Wysocki [this message]
2007-05-03 22:57 ` Moore, Robert
2007-05-03 23:22   ` Rafael J. Wysocki
2007-05-04  4:34     ` Alexey Starikovskiy
2007-05-04  8:50       ` Rafael J. Wysocki
2007-05-04 18:10         ` Moore, Robert
2007-05-04 20:09           ` 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=200705040055.39007.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    /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