From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 24 16:15:14 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BC7D205; Thu, 24 Oct 2013 16:15:14 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF8DE28E6; Thu, 24 Oct 2013 16:15:13 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r9OFpU7h014429; Thu, 24 Oct 2013 17:51:30 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r9OFpUHt014428; Thu, 24 Oct 2013 17:51:30 +0200 (CEST) (envelope-from marius) Date: Thu, 24 Oct 2013 17:51:30 +0200 From: Marius Strobl To: Nathan Whitehorn Subject: Re: Nexus improvements Message-ID: <20131024155130.GA14293@alchemy.franken.de> References: <5268332A.6080107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5268332A.6080107@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:15:14 -0000 On Wed, Oct 23, 2013 at 03:35:54PM -0500, Nathan Whitehorn wrote: > I've been trying for the last few days to clean up some of our OF/FDT > code, in particular related to reducing code duplication. There is a > 12-year-old comment in sparc64/sparc64/nexus.c that "this code should > get into dev/ofw to some extent". Most of the code has been moved now > and the PowerPC nexus device has been replaced by the pieces of the > sparc64 one that now do live in dev/ofw. The following (almost entirely > negative) patch moves sparc64 to use it as well. Since it is just a copy > of the sparc64 code, this should involve no functional changes, and I > will commit it in a few days unless someone raises an objection. The > patch is only compile tested for the time being, so hardware tests would > be appreciated. > > Patch at: http://people.freebsd.org/~nwhitehorn/sparc64-nexus-unify.diff Well, as is this patch breaks resource allocation in a strange way: nexus0: pcib0: mem 0x4000f600000-0x4000f6effff,0x4000f410000-0x4000f473fff irq 1983,1982 on nexus0 panic: fire_attach: could not allocate register bank 0 I didn't try to figure out what's going on as I'm still not very fond of sharing that code across platforms. The comment you are referring to is - as you are also pointing out - rather old and applied to a sparc64 nexus(4) that was quite different than the current version and f. e. didn't do resource management of its children based on OFW information. In particular, "true" MI code shouldn't have #ifdefs with very MD code like the one your patch would introduce. Similarly, the device exclude lists shouldn't be shared across all platforms as one might want to exclude a specific device whilst another does not. Having the whole lists in unconditionally also just wastes memory on embedded machinery. Also, switching sparc64 to use the current dev/ofw/ofw_nexus.c would introduce some subtle differences compared to how things currently work with the MD nexus(4). At a quick glance that would be: o the interrupts RMAN range gets extended from IV_MAX - 1 to ~0, which means no longer sanity checking for out-of-range interrupts, o devices without at least memory resources get added as children, while previously they were skipped. Marius