Date: Tue, 14 May 2013 10:14:42 -0700 From: Justin Hibbits <jrh29@alumni.cwru.edu> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: late suspend/early resume Message-ID: <CAHSQbTCEOfCH5tLeWgP4gPVbsBwDKLKBboQ2d74npkQomoJJJQ@mail.gmail.com> In-Reply-To: <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. On May 13, 2013 12:19 PM, "Warner Losh" <imp@bsdimp.com> wrote: > > > On May 13, 2013, at 1:14 PM, Julian Elischer wrote: > > > On 5/13/13 6:53 AM, Warner Losh wrote: > >> Where is the northbridge in the object tree hierarchy? > >> > >> Since you are asking this, I'm guessing it isn't at the top of the tree, and can't easily be. > >> > >> I don't like this idea. I think it is is silly and will lead only to additional proliferation of late late late early late calls. > >> > >> Much better would be for the suspend routine to return a number indicating how late to be called (and correspondingly how early resume should be called). this way the tree walking code can insert these devices into an ordered list that can then be walked at the end of suspend and traversed backwards at the start of resume. > >> > >> There are many embedded systems where there's a bit of a partial ordering between clock generation blocks and power blocks that need to be handled specially since there's no ACPI on those platforms to do things last. We don't model them well at all (or even at all), and having some mechanism in place to help with that would be useful. > >> > >> So in short I understand the need, but feel that the kobj extensions you propose are little better than the hard-coded calls and would like to see something a little more generic since the in-order traversal of the device tree seems a poor fit to 'special cases' like this. > > > > would not some dependency graph be more 'correct'? not sure how one would express it. Maybe by default it would go with the device hierarchy but with the ability to add extra dependencies. > > A numeric value would completely encapsulate the graph and avoid loops in said graph. Expressing the dependency graph would likely be a heavier lift as well... > > Warner > > >> Warner > >> > >> > >> On May 13, 2013, at 1:20 AM, Justin Hibbits wrote: > >> > >>> I'd like to solicit opinions on adding new kobj device API calls, > >>> device_late_suspend and device_early_resume. > >>> > >>> I've been working on PowerPC suspend/resume, and certain devices must be > >>> suspended last and resumed first on Apple hardware, namely the chipsets. > >>> It happens that one device (uninorth) appears first in the devinfo chain, > >>> while the other (mac-io) appears off a later PCI bus. So, rather than > >>> special casing this to suspend the mac-io and its children, as well as the > >>> uninorth, last with specific calls, I'd like to add a device_suspend_late > >>> and device_resume_early, that would simply be identical to > >>> device_suspend/device_resume, but could be called after and before, > >>> respectively, to do last minute order suspend and first pass > >>> initialization, to initialize things like clocks required for other devices. > >>> > >>> It's not difficult to explicitly call suspend and resume functions on the > >>> chipsets, but I think it's cleaner to do it through the newbus/kobj > >>> interface, and it might be useful for other architectures as well. > >>> > >>> Thoughts? > >>> > >>> - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTCEOfCH5tLeWgP4gPVbsBwDKLKBboQ2d74npkQomoJJJQ>