From owner-acpi-jp@jp.freebsd.org  Fri Sep  1 17:14:37 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id RAA62206;
	Fri, 1 Sep 2000 17:14:37 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id RAA62200;
	Fri, 1 Sep 2000 17:14:34 +0900 (JST)
	(envelope-from dfr@nlsystems.com)
Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com)
	by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1)
	id 13Ulxr-0001b2-0X; Fri, 1 Sep 2000 09:14:20 +0100
Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3])
	by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA30494;
	Fri, 1 Sep 2000 09:16:22 +0100 (BST)
	(envelope-from dfr@nlsystems.com)
Date: Fri, 1 Sep 2000 09:21:01 +0100 (BST)
From: Doug Rabson <dfr@nlsystems.com>
To: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
cc: acpi-jp@jp.freebsd.org, takawata@shidahara1.planet.sci.kobe-u.ac.jp,
        dfr@freebsd.org
In-Reply-To: <20000831192844V.iwasaki@jp.FreeBSD.org>
Message-ID: <Pine.BSF.4.21.0009010919310.24553-100000@salmon.nlsystems.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 597
Subject: [acpi-jp 597] Re: PCI changes affect ACPI bus space access code.
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: dfr@nlsystems.com

On Thu, 31 Aug 2000, Mitsuru IWASAKI wrote:

> > > >> DEVMETHOD access to parent.In this case,there is no way to reach nexus-pcib.
> > > >
> > > >OK, how about this as Doug suggested previously?
> > > 
> > > Seems good.That is better than my previous code,
> > > 
> > > >It seems to work for me and it's much closer to what you are trying to
> > > >achieve.  If not, please correct me.
> > > 
> > > Yes.
> > 
> > I like this version better.
> 
> Thanks, I'll commit like that later.
> 
> Going back to your comment,
> 
> > Is this an ordering problem, i.e., is ACPI initialised before nexus_pcib
> > is created? If thats the case, then I guess it should be ok in the short
> > term but long term, integrating ACPI into the newbus probe sequence should
> > make it possible to call methods on the pcib device_t.
> 
> I'd like to specify the priority of device probe/attach ordering for
> each devices.  Currently, the ordering is like this;
> 
> % dmesg | grep motherboard
> acpi0: <TOSHIB> on motherboard
> apm0: <APM BIOS> on motherboard
> npx0: <math processor> on motherboard
> pcib0: <Intel 82443MX host to PCI bridge> on motherboard
> 
> but we want
> 
> apm0: <APM BIOS> on motherboard
> npx0: <math processor> on motherboard
> pcib0: <Intel 82443MX host to PCI bridge> on motherboard
> acpi0: <TOSHIB> on motherboard
> 
> because PCI_Config region access can occur during ACPI initialisation,
> also probing apm can be failed after switching to SCI interrupt by
> enabling ACPI. i.e., acpi need to be probed/attached after pcib and
> apm in this case, but should be earlier as possible for ACPI PnP.

The second argument to BUS_ADD_CHILD defines the order that the children
are probed. The isa driver uses this to ensure that sensitive devices are
probed early and that PnP devices are probed after all the legacy devices
have claimed resources.


-- 
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 20 8348 3944


