[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200906102127.57136.rjw@sisk.pl>
Date: Wed, 10 Jun 2009 21:27:56 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Oliver Neukum <oliver@...kum.org>
Cc: Alan Stern <stern@...land.harvard.edu>,
linux-pm@...ts.linux-foundation.org,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch update] Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code)
On Wednesday 10 June 2009, Oliver Neukum wrote:
> Am Mittwoch, 10. Juni 2009 10:29:26 schrieb Rafael J. Wysocki:
> > Argh, I forgot about some important things.
> >
> > First, there are devices with no parent (actually, it would be much easier
> > if they had a default dummy parent, but that's a separate issue).
> >
> > Second, the parent has to be taken into account in the asynchronous resume
> > path too (which BTW is more complicated).
>
> What happens if the parent's parent is also suspended? It seems to me that
> you must code this recursively.
Hmm, I thought I did.
[Looks]
pm_request_resume(dev) will call pm_request_resume(dev->parent), if necessary,
and that will call pm_request_resume(dev->parent->parent) and so on. Each of
them will queue a work item and the one for the topmost parent will be queued
first. So, the resume requests for all parents will be executed before the
one for the device, due to the fact that the workqueue is singlethread.
Well, there is a bug related to it, namely pm_autosuspend() may change the
status to RPM_SUSPENDED after pm_request_resume() has changed it to
RPM_WAKE, that needs fixing.
Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists