From owner-acpi-jp@jp.freebsd.org  Thu Aug 31 15:03:40 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id PAA58182;
	Thu, 31 Aug 2000 15:03:40 +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 PAA58174;
	Thu, 31 Aug 2000 15:03:36 +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 e7V63Xr98107;
	Thu, 31 Aug 2000 15:03:34 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org, takawata@shidahara1.planet.sci.kobe-u.ac.jp
Cc: iwasaki@jp.FreeBSD.org, dfr@freebsd.org
In-Reply-To: <200008310327.MAA60220@shidahara1.planet.sci.kobe-u.ac.jp>
References: <20000831033134U.iwasaki@jp.FreeBSD.org>
	<200008310327.MAA60220@shidahara1.planet.sci.kobe-u.ac.jp>
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: <20000831150333W.iwasaki@jp.FreeBSD.org>
Date: Thu, 31 Aug 2000 15:03:33 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 142
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 593
Subject: [acpi-jp 593] 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

> >Ah, you meant that pcicfgregs:dev (device_t) is now mandatory for
> >pci_cfg{read/write}, right?
> 
> No.pci_cfg{read/write} function is no more exist. 

pci_cfg{read/write} was moved to sys/pci/pci_compat.c, but it doesn't matter.

> >Then how about just obtain device_t acpi (or nexus? not sure) and set
> >it to pcicfgregs:dev ?
> 
> It will not work.In new-bus system,to call DEVMETHOD,it is mandatory to 
> use device_t of the the driver where the DEVMETHOD is defined,and 
> usually	access ancestor can be accessed if DEVMETHOD is defined to forward 
> DEVMETHOD access to parent.In this case,there is no way to reach nexus-pcib.

OK, how about this as Doug suggested previously?

Index: acpica_osd.h
===================================================================
RCS file: /home/ncvs/src/sys/i386/include/acpica_osd.h,v
retrieving revision 1.2
diff -u -r1.2 acpica_osd.h
--- acpica_osd.h	2000/08/29 20:30:51	1.2
+++ acpica_osd.h	2000/08/31 05:14:11
@@ -30,13 +30,15 @@
 
 #include <sys/param.h>
 #include <sys/systm.h>
+#include <sys/bus.h>
 #include <machine/bus.h>
 #include <machine/vmparam.h>
 #include <sys/acpi.h>
 #include <vm/vm.h>
 #include <vm/pmap.h>
-#include <pci/pcivar.h>
 
+#include "pcib_if.h"
+
 #define ACPI_BUS_SPACE_IO	I386_BUS_SPACE_IO
 
 /*
@@ -47,6 +49,27 @@
 static void	OsdOutX(ACPI_IO_ADDRESS, UINT32, int);
 
 /*
+ * New-bus dependent code
+ */
+
+static device_t	get_pcib_device(void);
+
+static __inline device_t
+get_pcib_device()
+{
+	device_t	nexus, pcib;
+
+	if ((nexus = device_find_child(root_bus, "nexus", 0)) == NULL) {
+		return (NULL);
+	}
+	if ((pcib = device_find_child(nexus, "pcib", 0)) == NULL) {
+		return (NULL);
+	}
+
+	return (pcib);
+}
+
+/*
  * Platform/Hardware independent I/O interfaces
  */
 
@@ -200,21 +223,14 @@
 static __inline ACPI_STATUS
 OsdReadPciCfg(UINT32 Bus, UINT32 DeviceFunction, UINT32 Register, UINT32 *Value, int bytes)
 {
-	pcicfgregs	pcicfg;
+	static device_t	pcib = NULL;
 
-	/*
-	 * XXX Hack for Alpha(tsunami) systems.
-	 * pcicfg.hose is set to -1 in the hope that,
-	 * tsunami_cfgreadX() will set it up right.
-	 * Other Alpha systems (and i386's) don't seem to use hose.
-	 */
-	pcicfg.hose = -1;
-
-	pcicfg.bus = Bus;
-	pcicfg.slot = (DeviceFunction >> 16) & 0xff;
-	pcicfg.func = DeviceFunction & 0xff;
+	if (pcib == NULL && (pcib = get_pcib_device()) == NULL) {
+		return (AE_ERROR);
+	}
 
-	*Value = pci_cfgread(&pcicfg, Register, bytes);
+	*Value = PCIB_READ_CONFIG(pcib, Bus, (DeviceFunction >> 16) & 0xff,
+	    DeviceFunction & 0xff, Register, bytes);
 
 	return (AE_OK);
 }
@@ -264,21 +280,14 @@
 static __inline ACPI_STATUS
 OsdWritePciCfg(UINT32 Bus, UINT32 DeviceFunction, UINT32 Register, UINT32 Value, int bytes)
 {
-	pcicfgregs	pcicfg;
+	static device_t	pcib = NULL;
 
-	/*
-	 * XXX Hack for Alpha(tsunami) systems.
-	 * pcicfg.hose is set to -1 in the hope that,
-	 * tsunami_cfgreadX() will set it up right.
-	 * Other Alpha systems (and i386's) don't seem to use hose.
-	 */
-	pcicfg.hose = -1;
-
-	pcicfg.bus = Bus;
-	pcicfg.slot = (DeviceFunction >> 16) & 0xff;
-	pcicfg.func = DeviceFunction & 0xff;
+	if (pcib == NULL && (pcib = get_pcib_device()) == NULL) {
+		return (AE_ERROR);
+	}
 
-	pci_cfgwrite(&pcicfg, Register, Value, bytes);
+	PCIB_WRITE_CONFIG(pcib, Bus, (DeviceFunction >> 16) & 0xff,
+	    DeviceFunction & 0xff, Register, Value, bytes);
 
 	return (AE_OK);
 }

It seems to work for me and it's much closer to what you are trying to
achieve.  If not, please correct me.

> >I'm not sure this will work, but I prefer this way using more general
> >functions for portability reason rather than violating protected
> >nexus_pcib* stuff and accessing it directly.
> 
> It is sure the code I previously wrote is not desirable,but at present,
> there is no other way I think.I convince that constructing device tree 
> with ACPI or so,this can be cleanly solved.

Yes, agreed.  I love to see it.
BTW, I've thought of necessity for new-bus glue layer and also we
should make efforts to use more general functions where they are
available.  That was why I want to stay with pci_cfg* stuff.

