From owner-freebsd-hackers  Tue Jan 25  1:43:56 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from wyvern.cc.kogakuin.ac.jp (wyvern.cc.kogakuin.ac.jp [133.80.184.10])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9EF5614EEA; Tue, 25 Jan 2000 01:43:52 -0800 (PST)
	(envelope-from nyan@wyvern.cc.kogakuin.ac.jp)
Received: from localhost (localhost [127.0.0.1])
	by wyvern.cc.kogakuin.ac.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA54301;
	Tue, 25 Jan 2000 18:43:51 +0900 (JST)
To: luoqi@watermarkgroup.com
Cc: kato@ganko.eps.nagoya-u.ac.jp, FreeBSD-current@FreeBSD.ORG,
	FreeBSD-hackers@FreeBSD.ORG, FreeBSD98-hackers@jp.freebsd.org,
	nyan@jp.freebsd.org
Subject: Re: indirection in bus space
In-Reply-To: <200001250601.BAA17157@lor.watermarkgroup.com>
References: <200001250601.BAA17157@lor.watermarkgroup.com>
From: Takahashi Yoshihiro <nyan@wyvern.cc.kogakuin.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: <20000125184350C.nyan@wyvern.cc.kogakuin.ac.jp>
Date: Tue, 25 Jan 2000 18:43:50 +0900 (JST)
X-Dispatcher: imput version 990905(IM130)
Lines: 48
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In article <200001250601.BAA17157@lor.watermarkgroup.com>
Luoqi Chen <luoqi@watermarkgroup.com> writes:

> > I think it is difficult to implement such conversion because:
> > 
> >   - Not only bus space stuff also resource manager stuff need to
> >     perform such conversion.
> 
> Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be
> opaque types. Resource manager needs not know the implementation details.

In isa_alloc_resourcev() and isa_load_resourcev() (both new functions), 
it needs to store allocated resources and I/O table in
bus_space_handle_pc98.

> We could create a new resource type SYS_RES_IOPORT_ARRAY, and intercept
> it in all isa_*_resoruce() methods. In isa_alloc_resource(), we malloc and
> return a fake resource record, in which we store I386_BUS_PIO_IND as
> bus tag and address of bus_space_handle_pc98 as bus handle. And in
> isa_release_resource(), we first release the underlying resources stored
> in the bus_space_handle_pc98 record and then free the fake resource record
> itself. It should be safe as long as we don't manipulate this resource by
> direct resource manager calls, which we shouldn't do anyway.
> (or we should implement it at the root bus level, if pci devices in
> pc98 systems also use discrete port addresses).

We can't call bus_alloc_resource() directly from device drivers.
Because bus_alloc_resource() is defined as the following, it can't
deliver I/O table.

	struct  resource *
	bus_alloc_resource(device_t dev, int type, int *rid,
		u_long start, u_long end, u_long count, u_int flags);

If it conversion from 'bus_addr_t *' to 'u_long' and deliver to the
fourth argument, we can use bus_alloc_resource(). But, it needs to
perform conversions in each drivers using indirect resources.

Then, only isa_alloc_resourcev() is not enough to support NS8390 based
network cards and PnP devices which require to use I386_BUS_PIO_IND.
So, I separate into isa_alloc_resourcev() to allocate resources and
isa_load_resourcev() to store I/O table.

IMHO, as IBM PC/AT and NEC PC-98 is different architecture, the bus
space stuff should be implemented to different files.

---
Takahashi Yoshihiro / nyan@FreeBSD.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message