public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Pavel Machek <pavel@suse.cz>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	David Brownell <david-b@pacbell.net>
Subject: Re: [RFC] Fix Device Power Management States
Date: Wed, 11 Aug 2004 11:02:15 +1000	[thread overview]
Message-ID: <1092186134.14102.107.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.50.0408101539540.28789-100000@monsoon.he.net>

On Wed, 2004-08-11 at 08:41, Patrick Mochel wrote:
> On Tue, 10 Aug 2004, Pavel Machek wrote:
> 
> > I still do not see it... swsusp does not care about logical state of
> > device. (Actually manipulating logical state of device might make
> > swsusp less transparent). It cares about device not doing DMA (I also
> > said "no interrupts", but that is not strictly neccessary: we disable
> > interrupts for atomic copy. Device should do no NMIs, through).
> 
> Perhaps it is unncessary to do at a class level, at least at this point.
> I think we all agree that we need some sort of stop/start methods for
> devices, though. In which, we can add to struct bus_type:
> 
> 	int (*dev_stop)(struct device *);
> 	int (*dev_start)(struct device *);
> 
> Sound good?

Well, darwin has those, though I'm not sure if it's that necessary to
have them at all, well, maybe...

One thing is sure, having those at the class device level, if I
understand correctly, means we would have broken the ordering
requirement of always following the bus tree.

Honestly, I would stick to not having those at first, the PM callbacks
are enough for most cases, and just have "helpers" that the PM callbacks
call provided by their "class". For example, we could have a
netdev_quiesce_device() call that wuold wrap queue stopping and whatever
else (not much) has to be done at the network level.

IDE sort-of already has that via the PM request infrastructure, low
drivers only implement the few state machine steps they need for things
like cache flush or standby command. It would make sense to do a similar
mecanism for SCSI.

Honestly, there is really not that much to do related to class-side
start/stop, most of the work is usually at the driver level anyway from
experience (I implemented working PM for a bunch of drivers), there are
few things to take care with the "upper level", but not really that
much, and I would rather keep that as a helper function.

Let's keep things simple,

Ben.



  parent reply	other threads:[~2004-08-11  1:06 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-09 10:43 [RFC] Fix Device Power Management States Patrick Mochel
2004-08-09 11:38 ` Pavel Machek
2004-08-09 16:02   ` Patrick Mochel
2004-08-09 21:29     ` Pavel Machek
2004-08-10  5:03       ` Patrick Mochel
2004-08-10  9:43         ` Nigel Cunningham
2004-08-10 10:20           ` Pavel Machek
2004-08-10 22:33             ` Nigel Cunningham
2004-08-10 13:58           ` Patrick Mochel
2004-08-10 22:29             ` Nigel Cunningham
2004-08-10 22:56               ` Patrick Mochel
2004-08-10 23:09                 ` Nigel Cunningham
2004-08-10 23:36                   ` suspend2 merge [was Re: [RFC] Fix Device Power Management States] Pavel Machek
2004-08-11  0:04                     ` Arkadiusz Miskiewicz
2004-08-11  5:05                     ` Nigel Cunningham
2004-08-11  9:13                       ` Pavel Machek
2004-08-10 10:13         ` [RFC] Fix Device Power Management States Pavel Machek
2004-08-10 18:36           ` David Brownell
2004-08-10 20:36             ` Pavel Machek
2004-08-10 22:42             ` Patrick Mochel
2004-08-09 22:15     ` Nigel Cunningham
2004-08-10  0:43     ` Benjamin Herrenschmidt
2004-08-10  9:00       ` Russell King
2004-08-10 10:08       ` Pavel Machek
2004-08-10  0:40 ` Benjamin Herrenschmidt
2004-08-10  4:55   ` Patrick Mochel
2004-08-10  6:52     ` Benjamin Herrenschmidt
2004-08-10 10:07     ` Pavel Machek
2004-08-10 14:28       ` Patrick Mochel
2004-08-10 17:56         ` Pavel Machek
2004-08-10 22:41           ` Patrick Mochel
2004-08-10 23:10             ` Pavel Machek
2004-08-10 23:14             ` [patch] Smaller goal first: fix confusion [was Re: [RFC] Fix Device Power Management States] Pavel Machek
2004-08-11  1:02             ` Benjamin Herrenschmidt [this message]
2004-08-10 19:41     ` [RFC] Fix Device Power Management States David Brownell
2004-08-10 22:44       ` Patrick Mochel
2004-08-10 10:33 ` Matthew Garrett
2004-08-10 14:36   ` Patrick Mochel
2004-08-10 19:18 ` David Brownell
2004-08-10 20:50   ` Pavel Machek
2004-08-11  1:47 ` Todd Poynor
2004-08-12 22:03   ` Russell King

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=1092186134.14102.107.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.org \
    --cc=pavel@suse.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