> Again you misunderstood the question. The driver must start queued
I/O
> when its resume() method is called. It should then be okay for the
driver
> to call wake_up_interruptible(), even before tasks are unfrozen.
I kind of like the way MontaVista worked around this in some 2.4 drivers
where no freezer is present. A tiny amount of state is kept at the
driver and suspend lock outs are added at service entry points and at
thread wake up points inside of the driver.
This way if some process makes a request in or wakes up when the driver
is not ready for the action, that context will get re-slept.
With 2.6 on some of our variants for TI boards we still kept our suspend
lock outs even though the freezer was there. It allows some interesting
run time idling. You potentially can turn ON and OFF a driver
individually for something like a high latency operational mode. I
suppose based on your comments it also works around issues in the
freezer. It doesn't take all that many lock outs to shore up a driver.
Regards,
Richard W.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
