From owner-freebsd-arch@FreeBSD.ORG Tue May 14 17:14:45 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC3BDCF9; Tue, 14 May 2013 17:14:45 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 2378ABD5; Tue, 14 May 2013 17:14:44 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id jk13so485349bkc.3 for ; Tue, 14 May 2013 10:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NmRX2UsxufUKnYDis0bBWqtre8q0XxRQocrZ+rr/rjE=; b=LV13/cc1K+mduE9g9JNSpAbKDqwVmfyQ1OzzjNT1Yu0IEqgZK9rWZ1ZfojdbeyLDI0 p9CKw8vtL82rvE2ZDRyFI9S405y828kP+6FNVo/wks4/Axy/fGGcdy5e/aQV554Cixxr vxs6+28Ptvvks1cmpoGeUG3Ko4szDnAN3qy2Hho67fx1/PzvvP1oMs1CU3RmsDywGOcz R8eJaZog5TVGx8GCNxKv6PeUZRX4tVtS+o5oG2KG+l98dWL/v9ZFqX+EsSpERnpS0b+Z Igsc6dxlsRL0/xyis5BTqWtVRbX8Qqw5wHYuKtIPCkKsZsGQQ9y4ojYAM3mMb1LZwm/6 7IUQ== MIME-Version: 1.0 X-Received: by 10.204.71.77 with SMTP id g13mr9008543bkj.50.1368551683074; Tue, 14 May 2013 10:14:43 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.204.239.132 with HTTP; Tue, 14 May 2013 10:14:42 -0700 (PDT) Received: by 10.204.239.132 with HTTP; Tue, 14 May 2013 10:14:42 -0700 (PDT) In-Reply-To: <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> References: <51913B7D.1040801@freebsd.org> <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> Date: Tue, 14 May 2013 10:14:42 -0700 X-Google-Sender-Auth: Y9Dv_7tQd3z32Alh2Ifan8fnZaE Message-ID: Subject: Re: late suspend/early resume From: Justin Hibbits To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arch@freebsd.org 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: Tue, 14 May 2013 17:14:45 -0000 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" 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