From owner-acpi-jp@jp.freebsd.org  Thu Aug 31 19:29:03 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id TAA78871;
	Thu, 31 Aug 2000 19:29:03 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (daemon@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id TAA78863;
	Thu, 31 Aug 2000 19:28:59 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.10.2+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e7VAStr69750;
	Thu, 31 Aug 2000 19:28:55 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org, dfr@nlsystems.com
Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, iwasaki@jp.freebsd.org,
        dfr@freebsd.org
In-Reply-To: <Pine.BSF.4.21.0008311023220.24553-100000@salmon.nlsystems.com>
References: <200008310833.RAA71716@shidahara1.planet.sci.kobe-u.ac.jp>
	<Pine.BSF.4.21.0008311023220.24553-100000@salmon.nlsystems.com>
	<Pine.BSF.4.21.0008290913090.57011-100000@salmon.nlsystems.com>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000831192844V.iwasaki@jp.FreeBSD.org>
Date: Thu, 31 Aug 2000 19:28:44 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 42
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 596
Subject: [acpi-jp 596] 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: iwasaki@jp.freebsd.org

> > >> 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.
