Date: Fri, 13 Dec 2013 18:30:57 GMT From: John Baldwin <jhb@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 1189105 for review Message-ID: <201312131830.rBDIUvLq067118@skunkworks.freebsd.org>
index | next in thread | raw e-mail
http://p4web.freebsd.org/@@1189105?ac=10 Change 1189105 by jhb@jhb_jhbbsd on 2013/12/13 18:30:22 My thoughts on suspend and resume. Affected files ... .. //depot/projects/multipass/notes#7 edit Differences ... ==== //depot/projects/multipass/notes#7 (text+ko) ==== @@ -83,3 +83,46 @@ - We will need a way to destroy a resource manager, and something like device_set_desc_copy() where the rman allocates its own copy of the name and frees it on destroy. + +Thoughts about Suspend and Resume: +---------------------------------- +> I do like your idea of a device_t flag, but I'm not sure what the best +> way to go with that would be. I do already use a device_t flag to +> determine if the device is suspended, but only bus_generic_* access +> that in this patch. +> +> Would a better way be: +> * root_suspend instead of suspending its children, instead traverses +> and suspends each descendent in reverse order. +> * While doing this, insert each device upon successful suspend into a list. +> * For root_resume(), traverse the list back, and suspend each device +> in the reverse order. + +I would rather do it more the way that multipass attach now works where +you do scans of the entire device tree as you walk the pass number down +(during suspend) suspending any devices that are not yet suspended if +their pass number is >= current pass number, then on resume you do scans +of the entire tree raising the pass number back up using similar logic +to attach where you resume any suspended devices if the driver's pass +number is <= current pass number. + +> With this, add a new method, called device_suspend_child() to suspend +> a specific child if it hasn't already been suspended. + +Well, I would call it 'bus_suspend_child' and 'bus_resume_child' as +these would be bus methods in bus_if.m. + +> * This could require modifying the PCI driver to move the device +> child suspend/resume into those functions, instead of doing that logic +> in the device_suspend/device_resume itself. + +Correct. bus_generic_suspend() and bus_suspend_resume() would turn into +loops that look a lot like bus_generic_new_pass() (so the logic for +honoring pass numbers would happen in these routines and they would +invoke bus_suspend_child() and bus_resume_child() to change the state +of individual drivers). + +device_suspend() and device_resume() for the root device would look +like bus_set_pass() with a similar loop that walked through the pass +levels and invoked bus_generic_suspend/resume after each pass change +to start the pass across the device tree.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201312131830.rBDIUvLq067118>