From owner-freebsd-arch@FreeBSD.ORG Mon May 13 07:20:21 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 300E09B5 for ; Mon, 13 May 2013 07:20:21 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id BC4B6A86 for ; Mon, 13 May 2013 07:20:20 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id je9so2221450bkc.4 for ; Mon, 13 May 2013 00:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=pMnWzB/W4KxSpzMQCZSIjviQY/Ndf3TculULHHx2fio=; b=XYK2TsYl60ECMEsRczMGbm0CEpRrA41rIW2NQeLObfib0rpV5YMSksTwBV5T1uIg9K UCoVY6vTOZfdF4S9pbBzNUHn9ozGHvDVuUppLxFau9b2tg0pWaO4PExEVQIgs/J+DCMS t3GF9xMAxVey5kZ3CAuRNetJwtdHiFl5DtYTHWY2inJP7qcghBA7KSTJYpQzPSAn3vco Sz4kXceQhbwcam9sd+xj3oyiopux6Oy9YHZO6mCt2DTj3BX+DPedNGNe2EKeGFkBxzMn md7JNVXQUAMy8l5UeUdcHYJ6jF0IFxMfL3NfT6jX0NXL5GQAyXXwTR+L98NmlfjWz4uu 1wRQ== MIME-Version: 1.0 X-Received: by 10.204.172.80 with SMTP id k16mr5297384bkz.123.1368429619731; Mon, 13 May 2013 00:20:19 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.204.239.132 with HTTP; Mon, 13 May 2013 00:20:19 -0700 (PDT) Date: Mon, 13 May 2013 00:20:19 -0700 X-Google-Sender-Auth: DEfircN0VZ3BrD-UBmQJe9VU4O0 Message-ID: Subject: late suspend/early resume From: Justin Hibbits To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 07:20:21 -0000 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 From owner-freebsd-arch@FreeBSD.ORG Mon May 13 13:53:44 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 16A46873 for ; Mon, 13 May 2013 13:53:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id DE0B6695 for ; Mon, 13 May 2013 13:53:43 +0000 (UTC) Received: by mail-ia0-f179.google.com with SMTP id h37so2342153iak.10 for ; Mon, 13 May 2013 06:53:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=dkmwq4r6c0WTiQxJCoEWkN2iHv8+PjLXQ2mFlLbBtvQ=; b=VywBSzxDHqB2TZzg4Re+/jecSg4JULDaBXqslBC+4bM4dTfhgB+LKfJDBzUmkcZGcp 6Q1D83WLThAGwVxrPBRD48gcNRON90qf/OowxXLjCnPy6VHazyFzcmbdBChybhYB4qtR ptqbaAkzSs93DigGoNh4mYELTarhwD0nKPncNA3VYC0jh3QCmqTA3MkSX7NSPdsvdT9r QSIoLOYXbpvW/WuVS6yFdAvzG4cVRd5M2EQeWJCgJV4RqTOdeNoDDadO2e93rPotc7Du 5Ci2M71WPDNo/YCQkCQIvGtbJue1qtqpeO2Jjm4guMFkXbvgAChA8UwHpefu2QaP5F6V 8C0g== X-Received: by 10.42.84.201 with SMTP id n9mr12526247icl.47.1368453223441; Mon, 13 May 2013 06:53:43 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id xf4sm17265568igb.8.2013.05.13.06.53.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 06:53:41 -0700 (PDT) Sender: Warner Losh Subject: Re: late suspend/early resume Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 13 May 2013 07:53:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Justin Hibbits X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQklLNptU1b8koQstldcU3ZmcjN1P4KfFRVeitocFN/kKZWqD+j20iZ7VA8lXplQJObOEPOB 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: Mon, 13 May 2013 13:53:44 -0000 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. 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. >=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" 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" > From owner-freebsd-arch@FreeBSD.ORG Mon May 13 19:19:44 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 247E3FA9 for ; Mon, 13 May 2013 19:19:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 55652346 for ; Mon, 13 May 2013 19:19:43 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id eh20so1354089obb.4 for ; Mon, 13 May 2013 12:19:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=Iw9SeY9+4UxhsSh4q2Z8nZlgvDR63bUUi6YoIxzlJiM=; b=cmnYEHYbgfKGW2bXiSKhuF3cWt6B4q9iwLsiDfif9ryNdhkWHKEjVEEl0ePrfvscl1 Wcw/lTf6zylxls0/jRsglzP/1Vq0VGlRDSaWphZkRMNWU08Xnb877/9Q83kVnzL52NUk apFymrEFuq3AK4BGeeMozAU41H7oHEDjFzD/ZXQ0YI7+6KyVDkNzet0uHS4nOyYwwBPS dx41IMfjT+ty3OJerNgN2D/zs/Zk40vA9X1mMJIDKIZJ1gBebBGDW0bM+evYHG0RsJvK M4q4aw41NrY5bJ3WZ3j6dlUpfEWT3hXL+ujeEUBCX8unlc7O8agvf7xYzoBEi9nrsHPi hShg== X-Received: by 10.60.118.68 with SMTP id kk4mr6233653oeb.67.1368472782856; Mon, 13 May 2013 12:19:42 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id qj8sm18108354oeb.2.2013.05.13.12.19.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 12:19:41 -0700 (PDT) Sender: Warner Losh Subject: Re: late suspend/early resume Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51913B7D.1040801@freebsd.org> Date: Mon, 13 May 2013 13:19:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> References: <51913B7D.1040801@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnmcqIBLLiCGoOzSLjIUxILSItrM3y8nNM+fJBZhCfCtp4+MnLyjDo+QirsG5NaUv52S735 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: Mon, 13 May 2013 19:19:44 -0000 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" From owner-freebsd-arch@FreeBSD.ORG Mon May 13 20:12:02 2013 Return-Path: Delivered-To: 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 BD888803 for ; Mon, 13 May 2013 20:12:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 98E1B830 for ; Mon, 13 May 2013 20:12:02 +0000 (UTC) Received: from dhcp-10-2-212-236.hudson-trading.com (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8ECA8B918; Mon, 13 May 2013 16:11:59 -0400 (EDT) Message-ID: <51914914.805@FreeBSD.org> Date: Mon, 13 May 2013 16:12:04 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> <20130511043606.GE3047@kib.kiev.ua> In-Reply-To: <20130511043606.GE3047@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 May 2013 16:11:59 -0400 (EDT) Cc: 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: Mon, 13 May 2013 20:12:02 -0000 On 5/11/13 12:36 AM, Konstantin Belousov wrote: > On Fri, May 10, 2013 at 03:35:50PM -0400, John Baldwin wrote: >> Ok, here is a patch for 8 that reworks this to use a procctl(). If this looks >> reasonable I will port this to HEAD as two pieces: the first to add >> procctl() and the second to add PROCSPROTECT. > > This looks fine. > > Do we need the genericity of the ioctl for procctl ? > Ptrace(2) does not need the size encoded. > > I mean, the call is never marshalled to some unknown driver which needs > a size of parameters unknown to the generic layer. I suppose that all > additions to procctl() would have the size of the control structures > pre-defined. Then, you could just do copyin and, if needed, copyout > discrimating on the command code, and not on the encoding of the size in > the command. > > Also, command could be int and not long then, eliminating the need for > compat32 wrapper. Well, the generic-ness of ioctl() seemed useful to me. Also, I think with this model you could make fo_ioctl() for a process fd just do this: proc_ioctl(..., u_long cmd, caddr_t data) { pid = ; return (kern_procctl(td, P_PID, pid, cmd, data)); } So you could reuse procctl constants as ioctls for proc descriptors. It is true that unlike drivers there is currently no method to provide a "hook" to support new commands (they would just have to be added by hand into sys_process.c for now). Also, if we need to "thunk" structures for compat32 support in the future it is better if the kern_procctl() version takes a KVA rather than a UVA. OTOH, it is more boilerplate code to put in. In terms of a compat32 wrapper: id_t is a uint64_t, so a wrapper would be required regardless. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue May 14 11:02:02 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 B86FF908 for ; Tue, 14 May 2013 11:02:02 +0000 (UTC) (envelope-from oritm@mellanox.com) Received: from eu1sys200aog120.obsmtp.com (eu1sys200aog120.obsmtp.com [207.126.144.149]) by mx1.freebsd.org (Postfix) with ESMTP id 17ACF1C0 for ; Tue, 14 May 2013 11:02:00 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP ID DSNKUZIZoXMSn5y6A8VTszY3yQ5oyfdSsAWi@postini.com; Tue, 14 May 2013 11:02:01 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Tue, 14 May 2013 13:04:22 +0300 From: Orit Moskovich To: "freebsd-arch@freebsd.org" Subject: FreeBSD spinlock - compatibility layer Thread-Topic: FreeBSD spinlock - compatibility layer Thread-Index: Ac5QiaSgCms1CiujRJ+uiUawknitKQ== Date: Tue, 14 May 2013 10:04:21 +0000 Message-ID: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 11:02:02 -0000 Hi, I read about the FreeBSD mutex implementation for spinlock in the compatibi= lity layer. I might be wrong, but I noticed a code section that might be problematic: Taken from http://svn.freebsd.org/base/release/9.1.0/sys/ofed/include/linux= /spinlock.h: static inline void spin_lock_init(spinlock_t *lock) { memset(&lock->m, 0, sizeof(lock->m)); mtx_init(&lock->m, "lnxspin", NULL, MTX_DEF | MTX_NOWITNESS); } But MTX_DEF initializes mutex as a sleep mutex: By default, MTX_DEF mutexes will context switch when they are already held. There is a flag MTX_SPIN Which I think is the right one in this case . I'd appreciate your take on this issue. Thanks, Orit Moskovich From owner-freebsd-arch@FreeBSD.ORG Tue May 14 16:33:17 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD093ADD; Tue, 14 May 2013 16:33:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6DD8C9; Tue, 14 May 2013 16:33:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4EGXEUJ030387; Tue, 14 May 2013 19:33:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4EGXEUJ030387 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4EGXEEh030386; Tue, 14 May 2013 19:33:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 May 2013 19:33:14 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130514163313.GT3047@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> <20130511043606.GE3047@kib.kiev.ua> <51914914.805@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WRrpaeeXzhhJjPHD" Content-Disposition: inline In-Reply-To: <51914914.805@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: 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 16:33:17 -0000 --WRrpaeeXzhhJjPHD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 13, 2013 at 04:12:04PM -0400, John Baldwin wrote: > On 5/11/13 12:36 AM, Konstantin Belousov wrote: > > Do we need the genericity of the ioctl for procctl ? > > Ptrace(2) does not need the size encoded. > >=20 > > I mean, the call is never marshalled to some unknown driver which needs > > a size of parameters unknown to the generic layer. I suppose that all > > additions to procctl() would have the size of the control structures > > pre-defined. Then, you could just do copyin and, if needed, copyout > > discrimating on the command code, and not on the encoding of the size in > > the command. > >=20 > > Also, command could be int and not long then, eliminating the need for > > compat32 wrapper. >=20 > Well, the generic-ness of ioctl() seemed useful to me. Also, I think > with this model you could make fo_ioctl() for a process fd just do this: >=20 > proc_ioctl(..., u_long cmd, caddr_t data) > { >=20 > pid =3D ; > return (kern_procctl(td, P_PID, pid, cmd, data)); > } >=20 > So you could reuse procctl constants as ioctls for proc descriptors. It > is true that unlike drivers there is currently no method to provide a > "hook" to support new commands (they would just have to be added by hand > into sys_process.c for now). Also, if we need to "thunk" structures for > compat32 support in the future it is better if the kern_procctl() > version takes a KVA rather than a UVA. >=20 > OTOH, it is more boilerplate code to put in. Yes, I just do not see much need in it, but this is your call, finally. >=20 > In terms of a compat32 wrapper: id_t is a uint64_t, so a wrapper would > be required regardless. >=20 > --=20 > John Baldwin --WRrpaeeXzhhJjPHD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRkmdJAAoJEJDCuSvBvK1Br7cP/1noMtkDD5BBoDI9L8QqI2FC LSt6ba/2bUswxzg6eqg4p2JectPzSoLD14cap1ju+sz2q3RAg70t7WXDbaWcV5oo v+5XJ0CsUnxz2Jc93wquEkx9f4nm3uK5TFnra0Pf84ywXahOTcbe51idV1gX1xmS xvml1nGxlTlFUTZSdwFVX0TUS4gKIfmnhGOYJNjuDCYxiiByZKbOvmAF+RUdqyru 9tiFCo6OCyPsvDGJHEiJ1+hT3Wd8/TEFS/92529xbNXxiqtFmg6fro2DxrwX2mUm +3lpBxRv5ehtYIKtAg2rDiipQZfM8fYSNevy2fMO0VWJkIUmKdI3+qkjtwxvSZYo y1rxUW35QKBHLKazvJqVphLDtoinLn+d/tJmopWGMM2cAUVX7ULNuVxWjJxL2y8z wB/ywLy7VdzZmivR02F5tSgZs1RX557pBKwJv5oO0lahP931sFO1uOvi6N8SMytu 9Y9RayN6LpBdm6JGet1OiiMrNZZGe+mrknJKgOUJQ/3ysmuOTDnT2fXFAfdjCVnx P2QeddkFNz4d1bL69vs0HNvjpR9hzdgaXIKli0Tqs/J2DEu94864LeJrJ3KejDlJ 0ifiYlgbQQa/NkE8x/TXl/vJELrZQ08/5siUL3tX++PScvpQAU3Qli11TZku4BIc w5Y7f6FECp6HDR3ky73J =9HSj -----END PGP SIGNATURE----- --WRrpaeeXzhhJjPHD-- 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 From owner-freebsd-arch@FreeBSD.ORG Tue May 14 19:21:16 2013 Return-Path: Delivered-To: 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 3E36CBD5; Tue, 14 May 2013 19:21:16 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 076563F6; Tue, 14 May 2013 19:21:16 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 655763592DC; Tue, 14 May 2013 21:21:15 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 4F22F28493; Tue, 14 May 2013 21:21:15 +0200 (CEST) Date: Tue, 14 May 2013 21:21:15 +0200 From: Jilles Tjoelker To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130514192115.GA34869@stack.nl> References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201305101535.50633.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , 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 19:21:16 -0000 On Fri, May 10, 2013 at 03:35:50PM -0400, John Baldwin wrote: > [snip] > +int > +kern_procctl(struct thread *td, idtype_t idtype, id_t id, u_long com, > + void *data) > +{ > [snip] > + case P_PGID: > + /* > + * Attempt to apply the operation to all members of the > + * group. Ignore processes in the group that can't be > + * seen. Stop on the first error encountered. > + */ > + pg = pgfind(id); > + if (pg == NULL) { > + error = ESRCH; > + break; > + } > + PGRP_UNLOCK(pg); > + error = ESRCH; > + LIST_FOREACH(p, &pg->pg_members, p_pglist) { > + PROC_LOCK(p); > + if (p->p_state == PRS_NEW || > + p_cansee(td, p) != 0) { > + PROC_UNLOCK(p); > + continue; > + } > + error = kern_procctl_single(td, p, com, data); > + PROC_UNLOCK(p); > + if (error) > + break; > + } > + break; I think it does not really make sense that the set of affected processes depends on the order in &pg->pg_members. Comparing other functions, kill() returns success if it could signal any process (even it could not signal other processes matched by the argument). This is also most consistent with general POSIX/Unix philosophy that a function only fails if it committed no change (but there are various places where this is not the case). On the other hand, setpriority() affects all matches processes it can but returns an error if any one fails, even if some other process was affected. All this is not very important for process protection because it requires root privileges anyway but future procctl commands may well be accessible to normal users (I'm thinking of avoiding proliferation of pd* calls in particular). -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Tue May 14 21:36:56 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3291FA89 for ; Tue, 14 May 2013 21:36:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF45F39 for ; Tue, 14 May 2013 21:36:56 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (unknown [24.114.252.241]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5DB12B964; Tue, 14 May 2013 17:36:55 -0400 (EDT) Message-ID: <5192AE7C.10105@FreeBSD.org> Date: Tue, 14 May 2013 17:37:00 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jilles Tjoelker Subject: Re: Extending MADV_PROTECT References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> <20130514192115.GA34869@stack.nl> In-Reply-To: <20130514192115.GA34869@stack.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 14 May 2013 17:36:55 -0400 (EDT) Cc: Konstantin Belousov , 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 21:36:56 -0000 On 5/14/13 3:21 PM, Jilles Tjoelker wrote: > On Fri, May 10, 2013 at 03:35:50PM -0400, John Baldwin wrote: >> [snip] >> +int >> +kern_procctl(struct thread *td, idtype_t idtype, id_t id, u_long com, >> + void *data) >> +{ >> [snip] >> + case P_PGID: >> + /* >> + * Attempt to apply the operation to all members of the >> + * group. Ignore processes in the group that can't be >> + * seen. Stop on the first error encountered. >> + */ >> + pg = pgfind(id); >> + if (pg == NULL) { >> + error = ESRCH; >> + break; >> + } >> + PGRP_UNLOCK(pg); >> + error = ESRCH; >> + LIST_FOREACH(p, &pg->pg_members, p_pglist) { >> + PROC_LOCK(p); >> + if (p->p_state == PRS_NEW || >> + p_cansee(td, p) != 0) { >> + PROC_UNLOCK(p); >> + continue; >> + } >> + error = kern_procctl_single(td, p, com, data); >> + PROC_UNLOCK(p); >> + if (error) >> + break; >> + } >> + break; > > I think it does not really make sense that the set of affected processes > depends on the order in &pg->pg_members. > > Comparing other functions, kill() returns success if it could signal any > process (even it could not signal other processes matched by the > argument). This is also most consistent with general POSIX/Unix > philosophy that a function only fails if it committed no change (but > there are various places where this is not the case). On the other hand, > setpriority() affects all matches processes it can but returns an error > if any one fails, even if some other process was affected. > > All this is not very important for process protection because it > requires root privileges anyway but future procctl commands may well be > accessible to normal users (I'm thinking of avoiding proliferation of > pd* calls in particular). I originally used that approach in pprotect() since that is what ktrace uses. I did it this way in procctl() to err on the side of reporting errors vs not, but I can easily change it. This is something I wasn't sure of and very much appreciate feedback on. Do you have any thoughts on having this be more ioctl-like ("automatic" copyin/out and size encoded in cmd) vs ptrace-like (explicit sizes and in/out keyed off of command)? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed May 15 10:56:05 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 6E4669AA for ; Wed, 15 May 2013 10:56:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4621C6 for ; Wed, 15 May 2013 10:56:05 +0000 (UTC) Received: from John-Baldwins-MacBook-Air.local (unknown [24.114.252.241]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 72FB4B926; Wed, 15 May 2013 06:56:04 -0400 (EDT) Message-ID: <519369C4.6060402@FreeBSD.org> Date: Wed, 15 May 2013 06:56:04 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Justin Hibbits Subject: Re: late suspend/early resume References: <51913B7D.1040801@freebsd.org> <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 15 May 2013 06:56:04 -0400 (EDT) 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: Wed, 15 May 2013 10:56:05 -0000 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 From owner-freebsd-arch@FreeBSD.ORG Thu May 16 18:34:39 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 97743512; Thu, 16 May 2013 18:34:39 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id F320B9F5; Thu, 16 May 2013 18:34:38 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id jg9so1870650bkc.6 for ; Thu, 16 May 2013 11:34:38 -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=ZpeceN2dtavbix26/canzy2pU0+WKxYhGGOtggG+Hoc=; b=r1ii7V9oNc5mJvbdpwxKhV/NCzEqwWnhzA0buyELAacvJAMZowUf1ys+Cbp7Y1Nr76 ZVn7sV5L4UaEt3s7VJujfVstx9zz3+vMIEipK+0ay0w9deYiFoOul40oJU7Jo+eWbXYg N1HOgsjP7z/W/QOWLfK1mJET394a0ovpAJolojneqzPW1ehfHWNmlDRMZzhgaqdwKrKK sB6ZM8flAY4BfqLi6B3OfvyLLjUxR6Csd17cGHAU0cG4JyZRlGAFnJJfMchzZDyuC7cZ rop8ST4kvhWlJ1bf9e/I48ZVWiMlzKW8UfCMZ7QVWv8z1lLhULJsLFt5v09/ujCfR33+ MTnA== MIME-Version: 1.0 X-Received: by 10.204.108.196 with SMTP id g4mr14088689bkp.26.1368729277896; Thu, 16 May 2013 11:34:37 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.204.239.132 with HTTP; Thu, 16 May 2013 11:34:37 -0700 (PDT) In-Reply-To: <519369C4.6060402@FreeBSD.org> References: <51913B7D.1040801@freebsd.org> <288C9B9E-E943-4C5B-BCFB-15B721CBE94C@bsdimp.com> <519369C4.6060402@FreeBSD.org> Date: Thu, 16 May 2013 14:34:37 -0400 X-Google-Sender-Auth: W9rQDcIJCiC7CAEgITyLsTf5wXM Message-ID: Subject: Re: late suspend/early resume From: Justin Hibbits To: John Baldwin Content-Type: multipart/mixed; boundary=089e013c6200674aa504dcda1e10 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: Thu, 16 May 2013 18:34:39 -0000 --089e013c6200674aa504dcda1e10 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 15, 2013 at 6:56 AM, John Baldwin 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 Here's a (very) rough cut of what I think you're getting at. It uses the existing pass identifier to convey the current pass number, and walks the pass in reverse for suspend, and forwards for resume. However, I can't stress enough, that I only compiled it, I have no hardware here at BSDCan to test, so I have no idea if it will work as expected. The basic idea is to start at the last pass number, and any device can suspend and resume if able, or can check and return EAGAIN if it's not ready to suspend itself (it can still suspend its children if it wants). I could also add to bus_generic_resume() a check for the device's driver's pass wrt bus_current_pass, as in the probe code. Is this what you're thinking? - Justin --089e013c6200674aa504dcda1e10 Content-Type: application/octet-stream; name="suspend.diff" Content-Disposition: attachment; filename="suspend.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hgs9y82m0 SW5kZXg6IHN5cy9rZXJuL3N1YnJfYnVzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2tlcm4vc3Vicl9i dXMuYwkocmV2aXNpb24gMjQ4MjU1KQorKysgc3lzL2tlcm4vc3Vicl9idXMuYwkod29ya2luZyBj b3B5KQpAQCAtMTMwLDYgKzEzMCw3IEBACiAjZGVmaW5lCURGX0RPTkVOT01BVENICTB4MjAJCS8q IGRvbid0IGV4ZWN1dGUgREVWSUNFX05PTUFUQ0ggYWdhaW4gKi8KICNkZWZpbmUJREZfRVhURVJO QUxTT0ZUQyAweDQwCQkvKiBzb2Z0YyBub3QgYWxsb2NhdGVkIGJ5IHVzICovCiAjZGVmaW5lCURG X1JFQklECTB4ODAJCS8qIENhbiByZWJpZCBhZnRlciBhdHRhY2ggKi8KKyNkZWZpbmUgREZfU1VT UEVOREVECTB4MTAwCQkvKiBEZXZpY2UgaXMgc3VzcGVuZGVkLiAqLwogCXVfaW50CW9yZGVyOwkJ CS8qKjwgb3JkZXIgZnJvbSBkZXZpY2VfYWRkX2NoaWxkX29yZGVyZWQoKSAqLwogCXZvaWQJKml2 YXJzOwkJCS8qKjwgaW5zdGFuY2UgdmFyaWFibGVzICAqLwogCXZvaWQJKnNvZnRjOwkJCS8qKjwg Y3VycmVudCBkcml2ZXIncyB2YXJpYWJsZXMgICovCkBAIC0zNTMyLDE5ICszNTMzLDI5IEBACiBi dXNfZ2VuZXJpY19zdXNwZW5kKGRldmljZV90IGRldikKIHsKIAlpbnQJCWVycm9yOworCWludAkJ YWdhaW4gPSAwOwogCWRldmljZV90CWNoaWxkLCBjaGlsZDI7CiAKIAlUQUlMUV9GT1JFQUNIKGNo aWxkLCAmZGV2LT5jaGlsZHJlbiwgbGluaykgewotCQllcnJvciA9IERFVklDRV9TVVNQRU5EKGNo aWxkKTsKLQkJaWYgKGVycm9yKSB7Ci0JCQlmb3IgKGNoaWxkMiA9IFRBSUxRX0ZJUlNUKCZkZXYt PmNoaWxkcmVuKTsKLQkJCSAgICAgY2hpbGQyICYmIGNoaWxkMiAhPSBjaGlsZDsKLQkJCSAgICAg Y2hpbGQyID0gVEFJTFFfTkVYVChjaGlsZDIsIGxpbmspKQotCQkJCURFVklDRV9SRVNVTUUoY2hp bGQyKTsKLQkJCXJldHVybiAoZXJyb3IpOworCQlpZiAoIShjaGlsZC0+ZmxhZ3MgJiBERl9TVVNQ RU5ERUQpKSB7CisJCQllcnJvciA9IERFVklDRV9TVVNQRU5EKGNoaWxkKTsKKwkJCWlmIChlcnJv ciAmJiBlcnJvciAhPSBFQUdBSU4pIHsKKwkJCQlmb3IgKGNoaWxkMiA9IFRBSUxRX0ZJUlNUKCZk ZXYtPmNoaWxkcmVuKTsKKwkJCQkgICAgIGNoaWxkMiAmJiBjaGlsZDIgIT0gY2hpbGQ7CisJCQkJ ICAgICBjaGlsZDIgPSBUQUlMUV9ORVhUKGNoaWxkMiwgbGluaykpIHsKKwkJCQkJREVWSUNFX1JF U1VNRShjaGlsZDIpOworCQkJCQljaGlsZDItPmZsYWdzICY9IH5ERl9TVVNQRU5ERUQ7CisJCQkJ fQorCQkJCXJldHVybiAoZXJyb3IpOworCQkJfQorCQkJaWYgKGVycm9yID09IEVBR0FJTikgewor CQkJCWFnYWluID0gRUFHQUlOOworCQkJCWNvbnRpbnVlOworCQkJfQorCQkJY2hpbGQtPmZsYWdz IHw9IERGX1NVU1BFTkRFRDsKIAkJfQogCX0KLQlyZXR1cm4gKDApOworCXJldHVybiAoYWdhaW4p OwogfQogCiAvKioKQEAgLTM1NTcsMTIgKzM1NjgsMTkgQEAKIGJ1c19nZW5lcmljX3Jlc3VtZShk ZXZpY2VfdCBkZXYpCiB7CiAJZGV2aWNlX3QJY2hpbGQ7CisJaW50CQllcnJvciA9IDA7CiAKIAlU QUlMUV9GT1JFQUNIKGNoaWxkLCAmZGV2LT5jaGlsZHJlbiwgbGluaykgewotCQlERVZJQ0VfUkVT VU1FKGNoaWxkKTsKLQkJLyogaWYgcmVzdW1lIGZhaWxzLCB0aGVyZSdzIG5vdGhpbmcgd2UgY2Fu IHVzZWZ1bGx5IGRvLi4uICovCisJCWlmIChjaGlsZC0+ZmxhZ3MgJiBERl9TVVNQRU5ERUQpIHsK KwkJCWlmIChERVZJQ0VfUkVTVU1FKGNoaWxkKSA9PSBFQUdBSU4pIHsKKwkJCQllcnJvciA9IEVB R0FJTjsKKwkJCQljb250aW51ZTsKKwkJCX0KKwkJCS8qIGlmIHJlc3VtZSBmYWlscywgdGhlcmUn cyBub3RoaW5nIHdlIGNhbiB1c2VmdWxseSBkby4uLiAqLworCQkJY2hpbGQtPmZsYWdzICY9IH5E Rl9TVVNQRU5ERUQ7CisJCX0KIAl9Ci0JcmV0dXJuICgwKTsKKwlyZXR1cm4gKGVycm9yKTsKIH0K IAogLyoqCkBAIC00MzY3LDE1ICs0Mzg1LDM5IEBACiBzdGF0aWMgaW50CiByb290X3Jlc3VtZShk ZXZpY2VfdCBkZXYpCiB7Ci0JaW50IGVycm9yOworCXN0cnVjdCBkcml2ZXJsaW5rICpkbDsKKwlp bnQgZXJyb3IgPSAwOwogCi0JZXJyb3IgPSBidXNfZ2VuZXJpY19yZXN1bWUoZGV2KTsKKwlUQUlM UV9GT1JFQUNIKGRsLCAmcGFzc2VzLCBwYXNzbGluaykgeworCQlidXNfY3VycmVudF9wYXNzID0g ZGwtPnBhc3M7CisJCWVycm9yID0gYnVzX2dlbmVyaWNfcmVzdW1lKGRldik7CisKKwkJaWYgKGVy cm9yICE9IEVBR0FJTikKKwkJCWJyZWFrOworCX0KKwogCWlmIChlcnJvciA9PSAwKQogCQlkZXZj dGxfbm90aWZ5KCJrZXJuIiwgInBvd2VyIiwgInJlc3VtZSIsIE5VTEwpOwogCXJldHVybiAoZXJy b3IpOwogfQogCiBzdGF0aWMgaW50Cityb290X3N1c3BlbmQoZGV2aWNlX3QgZGV2KQoreworCXN0 cnVjdCBkcml2ZXJsaW5rICpkbDsKKwlpbnQgZXJyb3IgPSAwOworCisJVEFJTFFfRk9SRUFDSF9S RVZFUlNFKGRsLCAmcGFzc2VzLCBkcml2ZXJfbGlzdCwgcGFzc2xpbmspIHsKKwkJYnVzX2N1cnJl bnRfcGFzcyA9IGRsLT5wYXNzOworCQllcnJvciA9IGJ1c19nZW5lcmljX3Jlc3VtZShkZXYpOwor CQlpZiAoZXJyb3IgIT0gRUFHQUlOKQorCQkJYnJlYWs7CisJfQorCisJcmV0dXJuIChlcnJvcik7 Cit9CisKK3N0YXRpYyBpbnQKIHJvb3RfcHJpbnRfY2hpbGQoZGV2aWNlX3QgZGV2LCBkZXZpY2Vf dCBjaGlsZCkKIHsKIAlpbnQJcmV0dmFsID0gMDsKQEAgLTQ0MTIsNyArNDQ1NCw3IEBACiBzdGF0 aWMga29ial9tZXRob2RfdCByb290X21ldGhvZHNbXSA9IHsKIAkvKiBEZXZpY2UgaW50ZXJmYWNl ICovCiAJS09CSk1FVEhPRChkZXZpY2Vfc2h1dGRvd24sCWJ1c19nZW5lcmljX3NodXRkb3duKSwK LQlLT0JKTUVUSE9EKGRldmljZV9zdXNwZW5kLAlidXNfZ2VuZXJpY19zdXNwZW5kKSwKKwlLT0JK TUVUSE9EKGRldmljZV9zdXNwZW5kLAlyb290X3N1c3BlbmQpLAogCUtPQkpNRVRIT0QoZGV2aWNl X3Jlc3VtZSwJcm9vdF9yZXN1bWUpLAogCiAJLyogQnVzIGludGVyZmFjZSAqLwo= --089e013c6200674aa504dcda1e10--