public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <ambx1@neo.rr.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Andrew Morton <akpm@osdl.org>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [linux-pm] [patch] pm: fix runtime powermanagement's /sys	interface
Date: Sat, 7 Jan 2006 02:58:51 -0500	[thread overview]
Message-ID: <20060107075851.GD3184@neo.rr.com> (raw)
In-Reply-To: <20060107000826.GC20399@elf.ucw.cz>

On Sat, Jan 07, 2006 at 01:08:26AM +0100, Pavel Machek wrote:
> On Pá 06-01-06 10:42:24, Alan Stern wrote:
> > On Thu, 5 Jan 2006, Patrick Mochel wrote:
> > It's a very bad idea to make bus drivers export and manage the syfs power 
> > interface.  It means that lots of code gets repeated and different buses 
> > do things differently.
> > 
> > Already we have PCI exporting "pm_possible_states" and "pm_state" while 
> > PCMCIA exports "suspend".  How many other different schemes are going to 
> > crop up?  How much bus-specific information will have to be built into a 
> > user utility?
> > 
> > If possible states are represented as arrays of pointers to strings, then 
> > the PM core can easily supply the sysfs interface.  If Patrick's patch 
> > were re-written so that the sysfs interface were moved into the PM core, 
> > leaving only the PCI-specific portions in the PCI drivers, I would be much 
> > happier.  This would also mean that Dominik's patch could be replaced by 
> > something a good deal smaller.
> > 
> > And it wouldn't hurt to add some mechanism for indicating which of the 
> > possible states is the generic "suspend" state (usually D3 for PCI 
> > devices, but not necessarily).
> 
> I think we should start with string-based interface, with just two
> states ("on" and "off"). That is easily extensible into future, and
> suits current PCMCIA nicely. It also allows us to experiment with PCI
> power management... I can cook up a patch, but it will be simple
> reintroduction of .../power file under different name.

The driver core can provide some infustructure, but let's leave the states
up to the drivers.  Afterall, some drivers might only be interested in "on"
during runtime.  Also, drivers might support some sort of partial-off
but not "off".

And no, this does not allow us to experiment with PCI power management.
The runtime PM in drivers and some aspects of the PCI PM code (e.g. PME events
and saving/restoring device context) are terminally broken.  We really need a
good foundation for each bus PM spec.  There's a lot more to it than
just setting some bit in the PCI config space.

Also there's nothing "runtime" about the PCMCIA PM API.  It's much more
like calling ->remove() as it disabled the device all together.  I'm more
interested in saving power without crippling functionality.

Thanks,
Adam


  parent reply	other threads:[~2006-01-07  7:56 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-27 21:34 [patch] pm: fix runtime powermanagement's /sys interface Pavel Machek
2005-12-27 21:55 ` [linux-pm] " Dmitry Torokhov
2005-12-27 22:05   ` Pavel Machek
2005-12-28  4:22     ` Patrick Mochel
2006-01-04 21:34       ` Pavel Machek
2006-01-04 22:06         ` Alan Stern
2006-01-04 22:16           ` Pavel Machek
2006-01-05 21:43           ` Patrick Mochel
2006-01-05 22:06             ` Alan Stern
2006-01-05 22:28               ` Pavel Machek
2006-01-05 21:42         ` Patrick Mochel
2006-01-05 21:55           ` Pavel Machek
2006-01-05 22:13             ` Dominik Brodowski
2006-01-05 22:23               ` Pavel Machek
2006-01-05 22:27                 ` Dominik Brodowski
2006-01-05 22:59                   ` Pavel Machek
2006-01-05 23:08                   ` Pavel Machek
2006-01-05 23:46                     ` Dominik Brodowski
2006-01-05 23:58                       ` Pavel Machek
2006-01-06  0:04                         ` Patrick Mochel
2006-01-06  0:12                           ` Pavel Machek
2006-01-06  1:37                             ` Patrick Mochel
2006-01-06  8:59                               ` Pavel Machek
2006-01-07  5:47                                 ` Adam Belay
2006-01-06  9:00                               ` Pavel Machek
2006-01-06 15:00                               ` Dominik Brodowski
2006-01-07  5:58                                 ` Adam Belay
2006-01-06 15:42                               ` Alan Stern
2006-01-07  0:08                                 ` Pavel Machek
2006-01-07  3:19                                   ` Alan Stern
2006-01-07  7:58                                   ` Adam Belay [this message]
2006-01-07 10:20                                     ` Pavel Machek
2006-01-07 13:06                                       ` Adam Belay
2006-01-06  4:17                                         ` Pavel Machek
2006-01-07  7:41                                 ` Adam Belay
2006-01-07 15:24                                   ` Alan Stern
2006-01-06  0:38                   ` Greg KH
2006-01-06 15:03                     ` Dominik Brodowski
2006-01-06 16:25                       ` Kay Sievers
2006-01-09 20:10                         ` Dominik Brodowski
2006-01-05 22:15             ` Patrick Mochel
2006-01-05 22:44               ` Pavel Machek
2006-01-05 23:54                 ` Patrick Mochel
2006-01-06  0:07                   ` Pavel Machek
2006-01-06 14:34             ` Tom Marshall
2006-01-06 16:20               ` Pavel Machek
2006-01-07  8:36         ` Adam Belay
2006-01-07 10:25           ` Pavel Machek
2006-01-07 12:45             ` Adam Belay
2006-01-06  4:24               ` Pavel Machek
2006-01-13 20:00                 ` Takashi Iwai
  -- strict thread matches above, loose matches on Subject: below --
2006-01-05 15:16 Scott E. Preece
2006-01-05 16:41 ` Alan Stern
2006-01-05 21:14   ` Pavel Machek
2006-01-05 21:37     ` Alan Stern
2006-01-05 21:44       ` Pavel Machek
2006-01-05 21:48 ` Patrick Mochel
2006-01-05 22:13 Preece Scott-PREECE
2006-01-05 22:21 Preece Scott-PREECE
2006-01-05 22:45 ` Pavel Machek
2006-01-06  0:02 ` Patrick Mochel
2006-01-05 22:55 Preece Scott-PREECE
2006-01-05 23:05 ` Pavel Machek
2006-01-06  0:31 Scott E. Preece

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=20060107075851.GD3184@neo.rr.com \
    --to=ambx1@neo.rr.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=linux@dominikbrodowski.net \
    --cc=pavel@ucw.cz \
    --cc=stern@rowland.harvard.edu \
    /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