Date: Fri, 8 Aug 2003 08:36:17 +1000 From: John Birrell <jb@cimlogic.com.au> To: John Baldwin <jhb@freebsd.org> Cc: ticso@cicely.de Subject: Re: How to get a device_t Message-ID: <20030808083617.E7321@freebsd1.cimlogic.com.au> In-Reply-To: <XFMail.20030807102303.jhb@FreeBSD.org>; from jhb@freebsd.org on Thu, Aug 07, 2003 at 10:23:03AM -0400 References: <20030806.192742.85412759.imp@bsdimp.com> <XFMail.20030807102303.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ticso@cicely12.cicely.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030808083617.E7321>