From owner-p4-projects@FreeBSD.ORG Fri Dec 13 18:30:58 2013 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 426FB5A3; Fri, 13 Dec 2013 18:30:58 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 044465A1 for ; Fri, 13 Dec 2013 18:30:58 +0000 (UTC) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:1900:2254:2068::682:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C911F10E2 for ; Fri, 13 Dec 2013 18:30:57 +0000 (UTC) Received: from skunkworks.freebsd.org ([127.0.1.74]) by skunkworks.freebsd.org (8.14.7/8.14.7) with ESMTP id rBDIUvml067121 for ; Fri, 13 Dec 2013 18:30:57 GMT (envelope-from jhb@freebsd.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.7/8.14.7/Submit) id rBDIUvLq067118 for perforce@freebsd.org; Fri, 13 Dec 2013 18:30:57 GMT (envelope-from jhb@freebsd.org) Date: Fri, 13 Dec 2013 18:30:57 GMT Message-Id: <201312131830.rBDIUvLq067118@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to jhb@freebsd.org using -f From: John Baldwin Subject: PERFORCE change 1189105 for review To: Perforce Change Reviews Precedence: bulk X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.17 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:30:58 -0000 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.