Date: Mon, 13 May 2013 13:19:39 -0600 From: Warner Losh <imp@bsdimp.com> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: late suspend/early resume Message-ID: <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> In-Reply-To: <51913B7D.1040801@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? >>=20 >> Since you are asking this, I'm guessing it isn't at the top of the = tree, and can't easily be. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >=20 > 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 >>=20 >>=20 >> On May 13, 2013, at 1:20 AM, Justin Hibbits wrote: >>=20 >>> I'd like to solicit opinions on adding new kobj device API calls, >>> device_late_suspend and device_early_resume. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Thoughts? >>>=20 >>> - Justin >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >>=20 >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?288C9B9E-E943-4C5B-BCFB-15B721CBE94C>