public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Len Brown <lenb@kernel.org>
Cc: linux-pm@lists.linux-foundation.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: [patch 2.6.21-rc7] kconfig mentions 'hibernation' not just swsusp
Date: Sat, 21 Apr 2007 20:50:56 -0700	[thread overview]
Message-ID: <200704212050.57086.david-b@pacbell.net> (raw)
In-Reply-To: <200704212321.02822.lenb@kernel.org>

On Saturday 21 April 2007, Len Brown wrote:
> 
> >  	  In principle it does not require ACPI or APM, although for example
> > -	  ACPI will be used if available.
> > +	  ACPI will be used for the final steps when it is available.  One
> > +	  of the reasons to use software suspend is that the firmware hooks
> > +	  for suspend states like suspend-to-RAM (STR) often don't work very
> > +	  well with Linux.
> 
> I don't think the help section of a config options
> is a good place for editorial.

That doesn't seem "editorial" to me though.  It's a basic
engineering truth that's repeatedly been borne out over many,
many years.  The point of help text in Kconfig is, to my
thought, to help people understand why to choose something
(or not); knowing that firmware hooks (not purely ACPI) are
a factor would seem to be such help.

If I'd wanted to be "editorial", I'd have said something
more like:

	It's too bad chip vendors' video support for S2RAM
	still sucks so badly, and hardly looks to improve,
	since ACPI has improved so much in recent kernels.

	Today the "standby" suspend state works with Linux
	on most systems that support it, as does the "disk"
	(software suspend) state.   But suspend to "mem" is
	what most people want, since it's a lot quieter (and
	more power efficient) than "standby", and comes back
	a lot quicker than "disk".

	Until vendors of graphics silicon start providing
	enough chip specs to let Linux systems reliably
	restart graphics after suspend-to-RAM, anyone who
	wants to us suspend-to-RAM is advised to be VERY
	selective about video card support.  Choose only
	among the following video devices:  <insert short
	list here ... who should be on it??>

See the difference?  :)

... and yes, there are other drivers that may need tweaks to
work better with STR, but video has been the forever-headache.

- Dave

  reply	other threads:[~2007-04-22  3:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-22  3:02 [patch 2.6.21-rc7] kconfig mentioneds 'hibernation' not just swsusp David Brownell
2007-04-22  3:21 ` Len Brown
2007-04-22  3:50   ` David Brownell [this message]
2007-04-22  9:34 ` Rafael J. Wysocki
2007-04-22 14:58 ` Pavel Machek

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=200704212050.57086.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=lenb@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