Hi all.
Is there any existing code in the device model that supports resuming a
part of the device tree? For Suspend2, I'm wanting to resume storage
devices (and their parents) part way through resuming, and other drivers
later.
Regards,
Nigel
On Thu, 2004-03-04 at 07:03, Nigel Cunningham wrote:
> Hi all.
>
> Is there any existing code in the device model that supports resuming a
> part of the device tree? For Suspend2, I'm wanting to resume storage
> devices (and their parents) part way through resuming, and other drivers
> later.
What is your exact goal ? Not resuming all devices when writing the
state to the swap partition ?
You really need to resume it all at this point. However, the optimisation
that can be done is for some drivers to not put the HW to sleep on a
swsusp transition, only freeze the state. I did something like that in
IDE though that doesn't always work well due our "state" paremeter passed
down to drivers not beeing consistent.
Ben.
Hi.
My implementation saved the image in two parts. 'Pageset 2' contains the
LRU pages (active & inactive lists). 'Pageset 1' contains all other data
to be saved. At resume time, I read pageset 1 and copy the original
kernel data back. Then I want to resume the storage devices and read
pageset 2 before resuming all devices and waking everything else up. It
would also be good to not resume all devices when writing the state to
the swap partition, but I have other means of ensuring the consistency
of the image that mean I'm not so worried then.
Regards,
Nigel
On Thu, 2004-03-04 at 11:40, Benjamin Herrenschmidt wrote:
> On Thu, 2004-03-04 at 07:03, Nigel Cunningham wrote:
> > Hi all.
> >
> > Is there any existing code in the device model that supports resuming a
> > part of the device tree? For Suspend2, I'm wanting to resume storage
> > devices (and their parents) part way through resuming, and other drivers
> > later.
>
> What is your exact goal ? Not resuming all devices when writing the
> state to the swap partition ?
>
> You really need to resume it all at this point. However, the optimisation
> that can be done is for some drivers to not put the HW to sleep on a
> swsusp transition, only freeze the state. I did something like that in
> IDE though that doesn't always work well due our "state" paremeter passed
> down to drivers not beeing consistent.
>
> Ben.
>
--
On Thu, 2004-03-04 at 11:48, Nigel Cunningham wrote:
> Hi.
>
> My implementation saved the image in two parts. 'Pageset 2' contains the
> LRU pages (active & inactive lists). 'Pageset 1' contains all other data
> to be saved. At resume time, I read pageset 1 and copy the original
> kernel data back. Then I want to resume the storage devices and read
> pageset 2 before resuming all devices and waking everything else up. It
> would also be good to not resume all devices when writing the state to
> the swap partition, but I have other means of ensuring the consistency
> of the image that mean I'm not so worried then.
I don't see any good way to do that at this point. With a tree
structure, it would be possible to revive only the parents of
the storage device you are concerned in, but at this point, we
don't have this possibility
Ben.
Okay. I'll write it then. Thanks.
Nigel
On Thu, 2004-03-04 at 16:57, Benjamin Herrenschmidt wrote:
> On Thu, 2004-03-04 at 11:48, Nigel Cunningham wrote:
> > Hi.
> >
> > My implementation saved the image in two parts. 'Pageset 2' contains the
> > LRU pages (active & inactive lists). 'Pageset 1' contains all other data
> > to be saved. At resume time, I read pageset 1 and copy the original
> > kernel data back. Then I want to resume the storage devices and read
> > pageset 2 before resuming all devices and waking everything else up. It
> > would also be good to not resume all devices when writing the state to
> > the swap partition, but I have other means of ensuring the consistency
> > of the image that mean I'm not so worried then.
>
> I don't see any good way to do that at this point. With a tree
> structure, it would be possible to revive only the parents of
> the storage device you are concerned in, but at this point, we
> don't have this possibility
>
> Ben.
>
--