Date: Fri, 25 Oct 2013 19:17:41 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: Nexus improvements Message-ID: <20131025171741.GG962@alchemy.franken.de> In-Reply-To: <52694F9D.6000705@freebsd.org> References: <5268332A.6080107@freebsd.org> <20131024155130.GA14293@alchemy.franken.de> <52694F9D.6000705@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 24, 2013 at 11:49:33AM -0500, Nathan Whitehorn wrote: > On 10/24/13 10:51, Marius Strobl wrote: > >> > >> Patch at: http://people.freebsd.org/~nwhitehorn/sparc64-nexus-unify.diff > > Well, as is this patch breaks resource allocation in a strange way: > > nexus0: <Open Firmware Nexus device> > > pcib0: <Sun Host-PCIe bridge> mem 0x4000f600000-0x4000f6effff,0x4000f410000-0x4000f473fff irq 1983,1982 on nexus0 > > panic: fire_attach: could not allocate register bank 0 > > Odd. The resource allocation code is an exact copy of the one from > sparc64/nexus.c. I'll power up my SPARC machine and try to debug. Given that the resources actually are added correctly, I'd suspect that some of the expected parent/child relations break when deriving nexus_driver from ofw_nexus_driver but I don't get why this should have anything to do with the runtime hierarchy in the first place; this _could_ be a bug in newbus, though. > The only exception has to do with interrupt > numbering. SPARC doesn't seem to follow the Open Firmware > interrupt-mapping standard as far as I can tell That highly depends on the specific machine model; some are perfectly in line with the OFW standard, most but not all at least conform with it beneath the host-PCI-bridge level and a few are just odd here and there. The code in the tree mostly uses OFW means starting at the PCI level with some fallback and does interrupt numbering above always partially in a "manual" way, with the latter working on all models regardless of what information they provide in the respective OFW device tree. > Aside from resource allocation (which is maintained by the patch in MD > code) and this nit with IRQs, the PowerPC nexus is at present a > line-for-line copy of the sparc64 one. It seems a shame to maintain that > duplication. Well, on the other hand it's not that much additional code compared to other nexus(4) implementations that are more or less duplicated in the tree. Also, this stuff doesn't actually change that much over time. However, one thing that's currently missing on sparc64 is obtaining NUMA information; that again very likely will need additional tweaks to nexus(4) similar to what's already there for topologies involving ssm(4) given that OFW nodes representing single cores also are found in different spots in the device tree hierarchy depending on the machine model. All that said, IMO we're actually rather good at factoring out common OFW code into dev/ofw to the extent it really makes sense, apart from the fact that some FDT bits and stuff could make better (re-)use of the existing "true" OFW code, which you've already fixed recently or apparently are planning to do. > > > 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, > > This could be restored, though I can't imagine it adds much. At least in the past such "implicit" range checks turned out to be useful when adding support for new classes of sparc64 machines. > > o devices without at least memory resources get added as children, > > while previously they were skipped. > > Does it harm anything to add these? I'll try to fix the bugs in any > case, and then we can revisit the patch. No real "harm"; it just wastes a bit of memory to have devices in the FreeBSD device tree that no driver ever will attach to and the associated message the sparc64 nexus(4) emits when detecting such even registerless devices helps to identify nodes that are better added to the exclusion list. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131025171741.GG962>