Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues
From: Nigel Cunningham
Date: Fri Dec 17 2004 - 01:02:23 EST
On Fri, 2004-12-17 at 16:15, Michael Frank wrote:
> Hi Nigel,
> By what was discussed wrt ALSA issue I gather that you still resume _all_
> drivers after doing the atomic copy?
> As explained earlier this year, if this is the case, it is firstly
> unacceptable as it will result in loss of data in many applications and
> secondly very clumsy.
> Example With 2.4 OK, with 2.6 It would fail:
> A datalogger connected to a seral port of a notebook in the field. Data
> transfer in progress which can be put on hold bo lowering RTS (HW handshake)
> but _cannot_ be restarted. Battery low, must suspend to change battery, upon
> resume transfer can continue.
> Will this be taken care of?
Until 220.127.116.11, I had put in support ('device trees') for handling the
devices we're using in writing the image separately. Unused devices were
suspending prior to beginning to write the image and not resumed before
powerdown. At resume time, they were suspended and not resumed until the
whole image had been re-read. In short, it did what you're asking.
>From what I understand, though, work on the driver model and individual
drivers should be making this unnecessary. If that's not true, I'll
happily put the device tree code back in. For now, though, I've been
seeking to implement changes that will help with getting the code
merged, and this was one of them.
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901
You see, at just the right time, when we were still powerless, Christ
died for the ungodly. -- Romans 5:6
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/