Date: Thu, 23 May 2013 22:08:10 -0700 From: Justin Hibbits <jrh29@alumni.cwru.edu> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: late suspend/early resume Message-ID: <CAHSQbTDQQz1r%2BpsH3-Z6DESLoenXcjnefsNxZO7NtbboMtJ0rw@mail.gmail.com> In-Reply-To: <519369C4.6060402@FreeBSD.org> References: <CAHSQbTBNjrx=9DT7vk29D=Y%2BOK0qV=Ld4qN-sxy%2B8_OONazKAA@mail.gmail.com> <AE98E779-E22B-434D-9BEE-BF66241BB2E6@bsdimp.com> <51913B7D.1040801@freebsd.org> <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> <CAHSQbTCEOfCH5tLeWgP4gPVbsBwDKLKBboQ2d74npkQomoJJJQ@mail.gmail.com> <519369C4.6060402@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John, On Wed, May 15, 2013 at 3:56 AM, John Baldwin <jhb@freebsd.org> wrote: > On 5/14/13 1:14 PM, Justin Hibbits wrote: > > You are right that the late suspend could lead to silly proliferation, > and > > an ordered list is much better, but another API would need to be added to > > do that as well. > > > > My north bridge is first in the top list of the tree, right under the > > nexus, so to suspend it last I wrote the nexus suspend to traverse its > > children in reverse. The problem comes that the clock controller is > under a > > later PCI bus, not even the immediate following one, and the north bridge > > children are i2c devices, so suspending them after their clock head away > is > > problematic. We can discuss this more at bsdcan, where it may be easier > to > > describe. But essentially I need the north bridge and that pesky clock > > controller to be the last to suspend and the first to resume. I guess we > > can take this as the starting discussion for modeling this relationship > on > > all platforms, since you mention it is common in embedded platforms. > > I think you can do this by having a notion of passes with drivers having > a suspend pass level and doing passes over the tree suspending devices > at each pass level and then walking the passes back up in reverse during > resume. You could borrow from the multipass stuff used on probe/attach > for this. > > -- > John Baldwin > I have an update in the projects/pmac_pmu branch. It works for my PowerBook, but I'm not certain how well it will fare in the end, because of the way the PCI driver resumes its children. It doesn't call bus_generic_resume(), and instead suspends each child individually, which can lead to devices being resumed multiple times, but I'm uncertain how to fix that. Any ideas? One I had was to have some kind of 'bus_generic_resume_filtered' or similar, that lets bus_generic_resume run its logic, but filter through a function to determine if the child is resumable. But that doesn't quite feel right to me. - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTDQQz1r%2BpsH3-Z6DESLoenXcjnefsNxZO7NtbboMtJ0rw>