From owner-freebsd-arch@FreeBSD.ORG Mon May 13 19:14:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44B2DE2B for ; Mon, 13 May 2013 19:14:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED43308 for ; Mon, 13 May 2013 19:14:11 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r4DJEAFg088266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 13 May 2013 12:14:11 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51913B7D.1040801@freebsd.org> Date: Mon, 13 May 2013 12:14:05 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: late suspend/early resume References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:14:12 -0000 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. > 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 >> _______________________________________________ >> 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" >