[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200703311232.57505.david-b@pacbell.net>
Date: Sat, 31 Mar 2007 12:32:56 -0700
From: David Brownell <david-b@...bell.net>
To: linux-pm@...ts.linux-foundation.org
Cc: Adrian Bunk <bunk@...sta.de>,
Andrew Morton <akpm@...ux-foundation.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>, gregkh@...e.de,
Ingo Molnar <mingo@...e.hu>,
Jeff Chua <jeff.chua.linux@...il.com>,
Jens Axboe <jens.axboe@...cle.com>, jgarzik@...ox.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-acpi@...r.kernel.org, linux-ide@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-pci@...ey.karlin.mff.cuni.cz,
Maxim Levitsky <maximlevitsky@...il.com>,
"Michael S. Tsirkin" <mst@...lanox.co.il>,
Sergei Shtylyov <sshtylyov@...mvista.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET
On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute linux-pm@...ts.osdl.org from further messages!! )
>
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> >
> > i dont think there's any particular problem here because suspend/resume
> > wont be done during bootup - but we might need a way to move a device to
> > earlier spots in the device tree, even if they got registered later on -
> > instead of forcing the time devices to be registered very early?
>
> I'm about ready to test the appended patch... a "move one device" call
> might be safest at this point in the release cycle though.
As expected, this behaved OK on an x86 laptop. I'll see if it breaks
some of the ARM boards I have handy.
To be clear, what this means is that if "clockevent" and "clocksource"
devices get registered "very early", and the various clockevent and
clock source devices get registered, then the suspend/resume methods
for those will all get grouped together ... suspended "very late" and
resumed "very early", regardless of when they get registered. Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.
- Dave
> - Dave
>
> ======================== SNIP!
> Change how the PM list is constructed, so that devices are added right
> after their parents (when they have one) rather than at the end of the
> list. This preserves sequencing guarantees, but enables sequencing of
> suspend/resume operations by more important characteristics than "when
> device happened to enumerate" ... e.g. clocksources and clockevents
> at a clearly defined point during suspend and resume.
>
> This patch has a potential downside for devices that have multiple
> power dependencies and which "just happened to work" before.
>
> Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>
>
> --- g26.orig/drivers/base/power/main.c 2006-07-02 12:30:30.000000000 -0700
> +++ g26/drivers/base/power/main.c 2007-03-31 11:02:28.000000000 -0700
> @@ -52,12 +52,17 @@ EXPORT_SYMBOL_GPL(device_pm_set_parent);
> int device_pm_add(struct device * dev)
> {
> int error;
> + struct device *parent = dev->parent;
>
> - pr_debug("PM: Adding info for %s:%s\n",
> - dev->bus ? dev->bus->name : "No Bus", dev->kobj.name);
> + pr_debug("PM: Adding info for %s:%s, after %s\n",
> + dev->bus ? dev->bus->name : "No Bus", dev->kobj.name,
> + parent ? parent->bus_id : "(no parent)");
> down(&dpm_list_sem);
> - list_add_tail(&dev->power.entry, &dpm_active);
> - device_pm_set_parent(dev, dev->parent);
> + if (parent)
> + list_add(&dev->power.entry, &parent->power.entry);
> + else
> + list_add_tail(&dev->power.entry, &dpm_active);
> + device_pm_set_parent(dev, parent);
> if ((error = dpm_sysfs_add(dev)))
> list_del(&dev->power.entry);
> up(&dpm_list_sem);
>
-
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