[PATCH] Suspend2 Merge: Driver model patches 0/2

[PATCH] Suspend2 Merge: Driver model patches 0/2

[Nigel Cunningham]

Hi.

Here are two patches for the driver model, which have been in use in
suspend2 for around a month.

The first provides support for keeping part of the device tree alive
while suspending the remainder. This is accomplished by abstracting the
dpm_active, dpm_off and dpm_irq lists into a new struct partial device
tree, and providing functions to create new device trees and move
devices and their parents between trees. The current API for suspending
and resuming devices is completely unchanged by this patch. New
functions provide the extra functionality and existing functions are
wrappers that work on the default tree. Suspend2 uses this to keep the
storage device and graphics driver alive while putting other devices to
sleep at the start of saving the image.

The second patch adds a helper for finding a device_class given it's
name. This is used to locate the frame buffer drivers and (in
combination with the above patch) keep them alive while suspending other
drivers.

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

Re: [PATCH] Suspend2 Merge: Driver model patches 0/2

[Pavel Machek]

Hi!

> Here are two patches for the driver model, which have been in use in
> suspend2 for around a month.
> 
> The first provides support for keeping part of the device tree alive
> while suspending the remainder. This is accomplished by abstracting the
> dpm_active, dpm_off and dpm_irq lists into a new struct partial device

I believe this is wrong approach.

For atomic snapshot to work, all devices need to be stopped. If your
video card does DMA, it needs to be stopped. So all drivers need to
know, you can not just exclude part of tree.

Now, you probably do not want disks to spin down and you want your
screen unblanked (as an optimalization/speedup). Patch for keeping
disk up is allready in -mm. Patch for keeping radeonfb up looks like
this, and is pending, too.

If more such patches are needed, post them, but not telling drivers
based on their class is not an option.

								Pavel

--- clean-mm/drivers/video/aty/radeon_pm.c	2004-08-24 09:03:18.000000000 +0200
+++ linux-mm/drivers/video/aty/radeon_pm.c	2004-09-15 13:00:51.000000000 +0200
@@ -871,7 +871,8 @@
 	agp_enable(0);
 #endif
 
-	fb_set_suspend(info, 1);
+	if (system_state != SYSTEM_SNAPSHOT)
+		fb_set_suspend(info, 1);
 
 	if (!(info->flags & FBINFO_HWACCEL_DISABLED)) {
 		/* Make sure engine is reset */
@@ -880,12 +881,14 @@
 		radeon_engine_idle();
 	}
 
-	/* Blank display and LCD */
-	radeonfb_blank(VESA_POWERDOWN, info);
-
-	/* Sleep */
-	rinfo->asleep = 1;
-	rinfo->lock_blank = 1;
+	if (system_state != SYSTEM_SNAPSHOT) {
+		/* Blank display and LCD */
+		radeonfb_blank(VESA_POWERDOWN, info);
+
+		/* Sleep */
+		rinfo->asleep = 1;
+		rinfo->lock_blank = 1;
+	}
 
 	/* Suspend the chip to D2 state when supported
 	 */

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

Re: [PATCH] Suspend2 Merge: Driver model patches 0/2

[Nigel Cunningham]

Hi.

On Thu, 2004-09-16 at 21:18, Pavel Machek wrote:
> Hi!
> 
> > Here are two patches for the driver model, which have been in use in
> > suspend2 for around a month.
> > 
> > The first provides support for keeping part of the device tree alive
> > while suspending the remainder. This is accomplished by abstracting the
> > dpm_active, dpm_off and dpm_irq lists into a new struct partial device
> 
> I believe this is wrong approach.
> 
> For atomic snapshot to work, all devices need to be stopped. If your
> video card does DMA, it needs to be stopped. So all drivers need to
> know, you can not just exclude part of tree.

Sorry. Perhaps I wasn't clear enough. I do suspend these devices. But I
do it later:

Suspend all other drivers.
Write pageset 2 (page cache).
Suspend used drivers.
Make atomic copy.
Resume used drivers.
Write pageset 1 (atomic copy)
Suspend used drivers.
Power down all.

And vice versa at resume time.

> Now, you probably do not want disks to spin down and you want your
> screen unblanked (as an optimalization/speedup). Patch for keeping
> disk up is allready in -mm. Patch for keeping radeonfb up looks like
> this, and is pending, too.

Mm. Don't forget i8xx and the gazillion other drivers there :>. I see
this is using the SYSTEM_SNAPSHOT value. Do those changes look like
being merged to Linus soon?

Regards,

Nigel

-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

Re: [PATCH] Suspend2 Merge: Driver model patches 0/2

[Pavel Machek]

Hi!

> > > Here are two patches for the driver model, which have been in use in
> > > suspend2 for around a month.
> > > 
> > > The first provides support for keeping part of the device tree alive
> > > while suspending the remainder. This is accomplished by abstracting the
> > > dpm_active, dpm_off and dpm_irq lists into a new struct partial device
> > 
> > I believe this is wrong approach.
> > 
> > For atomic snapshot to work, all devices need to be stopped. If your
> > video card does DMA, it needs to be stopped. So all drivers need to
> > know, you can not just exclude part of tree.
> 
> Sorry. Perhaps I wasn't clear enough. I do suspend these devices. But I
> do it later:
> 
> Suspend all other drivers.
> Write pageset 2 (page cache).
> Suspend used drivers.
> Make atomic copy.
> Resume used drivers.
> Write pageset 1 (atomic copy)
> Suspend used drivers.
> Power down all.

What is problem with:

Write pageset 2
Suspend all drivers (avoiding slow operations)
Make atomic copy
Resume all drivers (avoiding slow operations)
Write pageset 1
Suspend all drivers
Power down all.

?

> > Now, you probably do not want disks to spin down and you want your
> > screen unblanked (as an optimalization/speedup). Patch for keeping
> > disk up is allready in -mm. Patch for keeping radeonfb up looks like
> > this, and is pending, too.
> 
> Mm. Don't forget i8xx and the gazillion other drivers there :>. I see
> this is using the SYSTEM_SNAPSHOT value. Do those changes look like
> being merged to Linus soon?

I still hope so. Patrick is back, so it could be merged by the end of
week... if we are lucky.
								Pavel

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

Re: [PATCH] Suspend2 Merge: Driver model patches 0/2

[Nigel Cunningham]

Hi.

On Thu, 2004-09-16 at 21:32, Pavel Machek wrote:
> > Sorry. Perhaps I wasn't clear enough. I do suspend these devices. But I
> > do it later:
> > 
> > Suspend all other drivers.
> > Write pageset 2 (page cache).
> > Suspend used drivers.
> > Make atomic copy.
> > Resume used drivers.
> > Write pageset 1 (atomic copy)
> > Suspend used drivers.
> > Power down all.
> 
> What is problem with:
> 
> Write pageset 2
> Suspend all drivers (avoiding slow operations)
> Make atomic copy
> Resume all drivers (avoiding slow operations)
> Write pageset 1
> Suspend all drivers
> Power down all.

It's always interesting trying to remember your logic for doing
something after the fact :>. If I recall correctly, it goes like this:

Writing two pagesets forces me to account for memory usage much more
carefully. I need to ensure before I start to write the image that I
know exactly what the size is and have allocated enough memory to do the
write. If I get some driver coming along and grabbing memory for who
knows what (hotplug, anyone? :>), I may get stuck halfway through
writing the image with no memory to use. I also have to be paranoid
about how much memory is available because I save that too (some of it
may have become slab by the time I do the atomic copy).

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

Re: [PATCH] Suspend2 Merge: Driver model patches 0/2

[Pavel Machek]

Hi!

> > > do it later:
> > > 
> > > Suspend all other drivers.
> > > Write pageset 2 (page cache).
> > > Suspend used drivers.
> > > Make atomic copy.
> > > Resume used drivers.
> > > Write pageset 1 (atomic copy)
> > > Suspend used drivers.
> > > Power down all.
> > 
> > What is problem with:
> > 
> > Write pageset 2
> > Suspend all drivers (avoiding slow operations)
> > Make atomic copy
> > Resume all drivers (avoiding slow operations)
> > Write pageset 1
> > Suspend all drivers
> > Power down all.
> 
> It's always interesting trying to remember your logic for doing
> something after the fact :>. If I recall correctly, it goes like this:
> 
> Writing two pagesets forces me to account for memory usage much more
> carefully. I need to ensure before I start to write the image that I
> know exactly what the size is and have allocated enough memory to do the
> write. If I get some driver coming along and grabbing memory for who
> knows what (hotplug, anyone? :>), I may get stuck halfway through
> writing the image with no memory to use. I also have to be paranoid
> about how much memory is available because I save that too (some of it
> may have become slab by the time I do the atomic copy).

What prevents video driver or disk driver to grab some memory? Tree
containing disk device can be pretty big [pci-usb-usb_hub-disk] and
contain some hot-pluggable components.

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

Re: [PATCH] Suspend2 Merge: Driver model patches 0/2

[Nigel Cunningham]

Hi.

On Thu, 2004-09-16 at 22:13, Pavel Machek wrote:
> > It's always interesting trying to remember your logic for doing
> > something after the fact :>. If I recall correctly, it goes like this:
> > 
> > Writing two pagesets forces me to account for memory usage much more
> > carefully. I need to ensure before I start to write the image that I
> > know exactly what the size is and have allocated enough memory to do the
> > write. If I get some driver coming along and grabbing memory for who
> > knows what (hotplug, anyone? :>), I may get stuck halfway through
> > writing the image with no memory to use. I also have to be paranoid
> > about how much memory is available because I save that too (some of it
> > may have become slab by the time I do the atomic copy).
> 
> What prevents video driver or disk driver to grab some memory? Tree
> containing disk device can be pretty big [pci-usb-usb_hub-disk] and
> contain some hot-pluggable components.

I do allow some slack to account for this (and slab), but I'm also
relying upon the same assumption you use: that the hardware present at
resume is the same as at suspend, and that the driver model
suspend/resume support will properly and successfully hold off any
activity until resume time.

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.