In article <[EMAIL PROTECTED]>
Luoqi Chen <[EMAIL PROTECTED]> 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 / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
