From owner-acpi-jp@jp.freebsd.org  Thu Aug 31 12:27:54 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id MAA47030;
	Thu, 31 Aug 2000 12:27:54 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id MAA47024;
	Thu, 31 Aug 2000 12:27:53 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1])
	by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id MAA60220;
	Thu, 31 Aug 2000 12:27:16 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Message-Id: <200008310327.MAA60220@shidahara1.planet.sci.kobe-u.ac.jp>
To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
Cc: acpi-jp@jp.FreeBSD.org, dfr@freebsd.org
In-reply-to: Your message of "Thu, 31 Aug 2000 03:31:34 JST."
             <20000831033134U.iwasaki@jp.FreeBSD.org>
Date: Thu, 31 Aug 2000 12:27:16 +0900
From: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 592
Subject: [acpi-jp 592] 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: takawata@shidahara1.planet.sci.kobe-u.ac.jp

In message <20000831033134U.iwasaki@jp.FreeBSD.org>, Mitsuru IWASAKI $B$5$s$$$o$/(B
:
>> >> Just for very short-term solution, is it enough to delete the lines
>> >> which access to pcicfgregs:hose in sys/i386/include/acpica_osd.h ?
>> >> It seems the problem had gone if I delete the lines, but I could be
>> >> wrong :-)
>> 
>> I don't think it work,because pcicfg{read/write} is replaced into
>> pcib_if.m method.How about this patch?
>
>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. 

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


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

Takanori Watanabe
<a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html">
Public Key</a>
Key fingerprint =  2C 51 E2 78 2C E1 C5 2D  0F F1 20 A3 11 3A 62 2A 










