PERFORCE change 1189105 for review

[John Baldwin]

http://p4web.freebsd.org/@@1189105?ac=10

Change 1189105 by jhb at 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.