From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 7 15:35:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA6E37B401; Thu, 7 Aug 2003 15:35:12 -0700 (PDT) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF4CD43FB1; Thu, 7 Aug 2003 15:35:08 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: from freebsd1.cimlogic.com.au (localhost.cimlogic.com.au [127.0.0.1]) by cimlogic.com.au (8.12.9/8.12.9) with ESMTP id h77MaQnp013687; Fri, 8 Aug 2003 08:36:26 +1000 (EST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.12.9/8.12.9/Submit) id h77MaJH3013680; Fri, 8 Aug 2003 08:36:19 +1000 (EST) Date: Fri, 8 Aug 2003 08:36:17 +1000 From: John Birrell To: John Baldwin Message-ID: <20030808083617.E7321@freebsd1.cimlogic.com.au> References: <20030806.192742.85412759.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@freebsd.org on Thu, Aug 07, 2003 at 10:23:03AM -0400 cc: ticso@cicely12.cicely.de cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: ticso@cicely.de Subject: Re: How to get a device_t X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 22:35:13 -0000 On Thu, Aug 07, 2003 at 10:23:03AM -0400, John Baldwin wrote: > > On 07-Aug-2003 M. Warner Losh wrote: > > In message: <20030807005810.GG35859@cicely12.cicely.de> > > Bernd Walter writes: > >: The host bridge is not available yet at probing time of the host bridge. > >: What we have is the host bridges parent (nexus) in the calling function. > >: Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or > >: we find it out later. > > > > Don't you mean legacy_pcib_is_host_bridge? That's where the matching > > is done in current right now (well, at least as of my last sync) If > > so, passing the host bridge's device down to it would be trivial to > > add. It would also allow other CPUs with builtin host bridges to do > > similar tricks to the one that is done for the ELAN. These sorts of > > features have been very common in other CPU families, and there's no > > reason to think that there won't be more of them in the x86 family as > > time goes on. > > > > I'm not sure that adding it to nexus at this stage of the boot would > > truly work. Since the legacy device has decided to attach, the nexus > > bus is already walking through its children. Adding a child during > > that walk strikes me as dangerous, since we have no locking on the > > children element of the device_t. Hmmm, looks I just found a source > > of problems in my newbus locking code that might explain some weird > > things happening when I enable it.... Thanks for making me go look :-) > > You would add it to legacy, not nexus. What you probably really want > to do is to write a host-PCI bridge driver that attaches to the actual > PCI device like 'hostb' and 'agp' do that creates a suitable child bus > for the MMCR stuff. This works for both ACPI and non-ACPI and doesn't > require hacking the legacy_pcib stuff. I'm not convinced that any hacking is required other than passing the device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. I traced the boot on my system and the MMCR is initialised early (when the Timecounter "ELAN" output occurs). Immediately following that initialisation, 'pcib' is added as a child of 'nexus'. I don't see why 'mmcr' couldn't be added as a child of 'nexus' too. At this point, nexus isn't walking through it's children so there shouldn't be a problem. Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. This seems straight forward. Maybe I'm missing something. 8-) -- John Birrell