From: David Brownell <david-b@pacbell.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>,
Maxim Levitsky <maximlevitsky@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] Add suspend/resume for HPET
Date: Wed, 4 Apr 2007 08:06:05 -0700 [thread overview]
Message-ID: <200704040806.06367.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0704021557270.29713-100000@netrider.rowland.org>
On Monday 02 April 2007 1:04 pm, Alan Stern wrote:
> On Mon, 2 Apr 2007, David Brownell wrote:
> > This is the kind of thing that the pm_parent relationship was (AFAICT)
> > originally supposed to handle. Of course, it doesn't/can't, given the
> > current implementation ... that relationship is never used.
>
> Just so. In fact, there almost certainly are other dependencies that
> nobody is aware of, simply because they have never had a chance to bite.
In any given system, yes there are bugs lurking. But I was more concerned
with a provably wrong assumption made by the current framework. Such things
cause cascading fragility.
As Thomas mentioned, HPET isn't the only place where a "linear" model fails.
> Such things can be rather difficult to pin down when they occur. I would
> be happy enough to leave matters as they are, with a strict LIFO approach.
I wouldn't. Much better to have a solid handle on the interdependencies
than to need to cope, long term, with a framework that doesn't allow that.
Remember also that a LIFO model assumes that there's only one sequence by
which the hardware powers up/down ... i.e. that there's no runtime PM going
on, whereby large chunks are regularly powered down/up based on usage.
Better runtime PM becomes more important as system complexity rises.
- Dave
WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg KH <greg@kroah.com>, Thomas Gleixner <tglx@linutronix.de>,
Kernel development list <linux-kernel@vger.kernel.org>,
Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET
Date: Wed, 4 Apr 2007 08:06:05 -0700 [thread overview]
Message-ID: <200704040806.06367.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0704021557270.29713-100000@netrider.rowland.org>
On Monday 02 April 2007 1:04 pm, Alan Stern wrote:
> On Mon, 2 Apr 2007, David Brownell wrote:
> > This is the kind of thing that the pm_parent relationship was (AFAICT)
> > originally supposed to handle. Of course, it doesn't/can't, given the
> > current implementation ... that relationship is never used.
>
> Just so. In fact, there almost certainly are other dependencies that
> nobody is aware of, simply because they have never had a chance to bite.
In any given system, yes there are bugs lurking. But I was more concerned
with a provably wrong assumption made by the current framework. Such things
cause cascading fragility.
As Thomas mentioned, HPET isn't the only place where a "linear" model fails.
> Such things can be rather difficult to pin down when they occur. I would
> be happy enough to leave matters as they are, with a strict LIFO approach.
I wouldn't. Much better to have a solid handle on the interdependencies
than to need to cope, long term, with a framework that doesn't allow that.
Remember also that a LIFO model assumes that there's only one sequence by
which the hardware powers up/down ... i.e. that there's no runtime PM going
on, whereby large chunks are regularly powered down/up based on usage.
Better runtime PM becomes more important as system complexity rises.
- Dave
next prev parent reply other threads:[~2007-04-04 15:06 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-02 14:16 [linux-pm] [PATCH v2] Add suspend/resume for HPET Alan Stern
2007-04-02 17:09 ` Linus Torvalds
2007-04-02 17:09 ` [linux-pm] " Linus Torvalds
2007-04-02 19:16 ` David Brownell
2007-04-02 19:16 ` [linux-pm] " David Brownell
2007-04-02 20:04 ` Alan Stern
2007-04-02 20:04 ` [linux-pm] " Alan Stern
2007-04-03 5:54 ` Thomas Gleixner
2007-04-03 5:54 ` [linux-pm] " Thomas Gleixner
2007-04-04 15:06 ` David Brownell [this message]
2007-04-04 15:06 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2007-03-16 16:33 Linux 2.6.21-rc4 Linus Torvalds
2007-03-29 5:47 ` [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions Maxim
2007-03-29 16:35 ` Linus Torvalds
2007-03-29 16:51 ` Maxim Levitsky
2007-03-29 17:22 ` Linus Torvalds
2007-03-29 17:47 ` [patch, v2] add suspend/resume for HPET Ingo Molnar
2007-03-29 17:47 ` Ingo Molnar
2007-03-29 13:20 ` [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions Sergei Shtylyov
2007-03-29 13:31 ` Maxim
2007-03-29 13:46 ` [PATCH v2] Add suspend/resume for HPET Maxim Levitsky
2007-03-29 13:46 ` Maxim Levitsky
2007-03-29 16:53 ` Linus Torvalds
2007-03-29 16:53 ` Linus Torvalds
2007-03-29 17:28 ` Maxim Levitsky
2007-03-29 17:51 ` Ingo Molnar
2007-03-29 17:51 ` Ingo Molnar
2007-03-29 20:46 ` Andi Kleen
2007-03-29 20:46 ` Andi Kleen
2007-03-29 18:11 ` Jeff Chua
2007-03-31 15:51 ` Thomas Gleixner
2007-03-31 15:51 ` Thomas Gleixner
2007-03-31 16:01 ` Jeff Chua
2007-03-31 16:01 ` Jeff Chua
2007-03-31 16:09 ` Thomas Gleixner
2007-03-31 16:09 ` Linus Torvalds
2007-03-31 16:09 ` Linus Torvalds
2007-03-31 16:33 ` Thomas Gleixner
2007-03-31 16:41 ` Greg KH
2007-03-31 16:53 ` Linus Torvalds
2007-03-31 16:53 ` Linus Torvalds
2007-03-31 17:02 ` Ingo Molnar
2007-03-31 17:02 ` Ingo Molnar
2007-03-31 18:18 ` David Brownell
2007-03-31 18:18 ` [linux-pm] " David Brownell
2007-03-31 19:32 ` David Brownell
2007-04-01 3:13 ` Jeff Chua
2007-04-01 4:13 ` David Brownell
2007-03-31 19:32 ` David Brownell
2007-03-31 17:08 ` Greg KH
2007-03-31 16:56 ` Maxim Levitsky
2007-03-31 17:09 ` Linus Torvalds
2007-03-31 17:09 ` Linus Torvalds
2007-03-31 17:17 ` Ingo Molnar
2007-03-31 17:17 ` Ingo Molnar
2007-03-31 17:58 ` Daniel Walker
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=200704040806.06367.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=maximlevitsky@gmail.com \
--cc=mingo@elte.hu \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.