device model documentation 2/3
Hi!
Quoted 10 lines
Quoted 9 lines
Quoted 4 lines
SUSPEND_DISABLEtells the device to stop I/O transactions. When it stops transactions, or what it should do with unfinished transactions is a policy of the driver. After this call, the driver should not accept any other I/O requests.Does this mean that memory allocations in the suspend/resume implementations must be made with
GFP_NOIOrespectivelyGFP_ATOMIC?
It would seem so.
Quoted 6 lines
Why would you allocate memory on a resume transition?
As for suspending, this is something that has been discussed a few times before. No definitive decision has come out of it because it hasn't been implemented yet. It hasn't been implemented yet because the infrastructure isn't complete. It's real close, but still not quite there.
swsusp works for me (tm). SO structure should be there ;-)
Quoted 3 lines
Nonetheless, you have to do one of a couple things: use
GFP_NOIOor special case the swap device(s) so they don't stop I/O when everything else does. (Of course, you have to eventually stop it)
Special casing swap is not enough -- you can well have memory full of data for regular filesystem.
Pavel
Signature · 13 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
Whether suspend is called with a given level is a policy of the platform. Some levels may be omitted; drivers must not assume the reception of any level. However, all levels must be called in the order above; i.e. notification will always come before disabling; disabling the device will come before suspending the device.
All calls are made with interrupts enabled, except for the
SUSPEND_POWER_DOWNlevel.
This is a slight problem for USB. We need to switch on interupts to send a message to the device. Is this provided for ?
Regards
Oliver
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
SUSPEND_DISABLEtells the device to stop I/O transactions. When it stops transactions, or what it should do with unfinished transactions is a policy of the driver. After this call, the driver should not accept any other I/O requests.
Does this mean that memory allocations in the suspend/resume implementations must be made with GFP_NOIO respectively GFP_ATOMIC ?
It would seem so.
Regards
Oliver
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Oliver Neukum
Quoted 7 lines
Whether suspend is called with a given level is a policy of the platform. Some levels may be omitted; drivers must not assume the reception of any level. However, all levels must be called in the order above; i.e. notification will always come before disabling; disabling the device will come before suspending the device.
Quoted 5 lines
Quoted 2 lines
All calls are made with interrupts enabled, except for the
SUSPEND_POWER_DOWNlevel.This is a slight problem for USB. We need to switch on interupts to send a message to the device. Is this provided for ?
Well, it all depends on what you want to do with USB devices during a suspend transition. I missed some of the discussion in the last few days, and I know you guys talked about it a little (I'm on the hotplug list, but I don't always pay attention ;) It's also been talked about before, though I don't think anything has come out of it.
IIRC, USB device state won't be saved across power transitions. It will look like a "disconnect", and "reconnect" on resume. (Forgive me if that's not the right USB terminology; I'm just guessing). In that case, when the controller gets the SUSPEND_DISABLE call, it can shutdown all the devices, and you're done. Right?
-pat
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Oliver Neukum
Quoted 5 lines
SUSPEND_DISABLEtells the device to stop I/O transactions. When it stops transactions, or what it should do with unfinished transactions is a policy of the driver. After this call, the driver should not accept any other I/O requests.Does this mean that memory allocations in the suspend/resume implementations must be made with
GFP_NOIOrespectivelyGFP_ATOMIC?
It would seem so.
Why would you allocate memory on a resume transition?
As for suspending, this is something that has been discussed a few times before. No definitive decision has come out of it because it hasn't been implemented yet. It hasn't been implemented yet because the infrastructure isn't complete. It's real close, but still not quite there.
Nonetheless, you have to do one of a couple things: use GFP_NOIO or special case the swap device(s) so they don't stop I/O when everything else does. (Of course, you have to eventually stop it)
Check the archives; there are lots of ideas there wrt this topic. But, there are bigger fish to fry in the meantime ;)
-pat
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
IIRC, USB device state won't be saved across power transitions. It will look like a "disconnect", and "reconnect" on resume. (Forgive me if that's not the right USB terminology; I'm just guessing). In that case, when the controller gets the
SUSPEND_DISABLEcall, it can shutdown all the devices, and you're done. Right?
IIRC some USB devices can do power saving. At least the pwc module has a module parameter to that effect.
Regards
Oliver
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Am Mittwoch, 5. Juni 2002 21:11 schrieb Patrick Mochel:
Quoted 6 lines · Oliver Neukum
Quoted 5 lines
Quoted 4 lines
SUSPEND_DISABLEtells the device to stop I/O transactions. When it stops transactions, or what it should do with unfinished transactions is a policy of the driver. After this call, the driver should not accept any other I/O requests.
Quoted 6 lines
Quoted 4 lines
Does this mean that memory allocations in the suspend/resume implementations must be made with
GFP_NOIOrespectivelyGFP_ATOMIC?
It would seem so.Why would you allocate memory on a resume transition?
We need to send messages to the device to restore state, don't we ? Any activity on USB can allocate memory. We've had to change the API to fix deadlock problems due to this already.
Regards
Oliver
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel