mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	David Brownell <david-b@pacbell.net>
Subject: Re: [RFC] Fix Device Power Management States
Date: Tue, 10 Aug 2004 19:56:37 +0200	[thread overview]
Message-ID: <20040810175637.GB28113@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.50.0408100700460.13807-100000@monsoon.he.net>

HI!

> > Can you explain why this class-based quiescing is good idea? It seems
> > to me that "quiesce this tree" is pretty much same as "suspend this
> > tree", and can be handled in the same way.
> >
> > Nigel wanted to do class-based quiescing, but if we make quiescing
> > fast enough, it should be okay to do whole tree, always. (And I
> > believe quiescing *can* be fast enough).
> 
> It has nothing to do with speed and everything to do with domains of
> responsibility. Each device belongs to 1 device class.  That class and the
> assoicated class device represent the functional interface(s) to the
> physical device. While the physical device controls physical attributes,
> like actual I/O and power states, the class controls the logical
> interface.

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).

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

  reply	other threads:[~2004-08-10 18:25 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-09 10:43 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 [this message]
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             ` [RFC] Fix Device Power Management States Benjamin Herrenschmidt
2004-08-10 19:41     ` 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=20040810175637.GB28113@elf.ucw.cz \
    --to=pavel@suse.cz \
    --cc=benh@kernel.crashing.org \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.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

all inboxes | Powered by JetHome®