From owner-acpi-jp@jp.freebsd.org  Wed Aug 30 17:35:32 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id RAA82515;
	Wed, 30 Aug 2000 17:35:32 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id RAA82504;
	Wed, 30 Aug 2000 17:35:28 +0900 (JST)
	(envelope-from dfr@nlsystems.com)
Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com)
	by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
	id 13U3L1-0004QE-0B; Wed, 30 Aug 2000 08:35:16 +0000
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 JAA22367;
	Wed, 30 Aug 2000 09:36:33 +0100 (BST)
	(envelope-from dfr@nlsystems.com)
Date: Wed, 30 Aug 2000 09:41:44 +0100 (BST)
From: Doug Rabson <dfr@nlsystems.com>
To: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, dfr@freebsd.org,
        msmith@freebsd.org, acpi-jp@jp.freebsd.org
In-Reply-To: <20000830031615L.iwasaki@jp.FreeBSD.org>
Message-ID: <Pine.BSF.4.21.0008300938420.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 589
Subject: [acpi-jp 589] 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 Wed, 30 Aug 2000, Mitsuru IWASAKI wrote:

> Hi,
> 
> > On Tue, 29 Aug 2000, Takanori Watanabe wrote:
> > 
> > > Hi, now I am merging ACPI support code and I have a problem.
> > > 
> > > Due to the change to PCI-PCIB interface you made yesterday,
> > > Our PCI configruation access code should be modified,
> > > but pcib_if code  cannot be used in ACPI module because ACPI 
> > > module do not know about device_t of  PCI *for now*. 
> > > Indeed,THE RIGHT WAY is to recognize new-bus device tree to ACPI,I think,
> > > but it need farther discussion to be done.
> > > So may I export nexus_pcib_*_config functions for a time being?
> > 
> > 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.
> 
> The urgent problem is that kernel compilation is failed with the files
> which include sys/i386/include/acpica_osd.h.  The file has
> 
>         pcicfgregs      pcicfg;
> 
>         /*
>          * 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;
> 
> 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 :-)

This is not sufficient. You probably need to do something like
pci_ioctl() does to implement PCIOCREAD - i.e. find the right pcib
instance and call the PCIB_READ_CONFIG method of that device.

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


