Subject: Re: Proposed extension to bus.h interface
To: None <>
From: Mike Long <>
List: tech-kern
Date: 08/15/1996 18:25:02
>From: Jason Thorpe <>
>Date: Wed, 14 Aug 1996 10:51:52 -0700

>	int bus_io_alloc(t, size, alignment, iohp)
>		bus_chipset_tag_t t;
>		bus_io_size_t size, alignment;
>		bus_io_handle_t *iohp;
>	Allocate bus i/o space of size `size' with alignment `alignment'.
>	If no alignment is required, the caller will pass the placeholder
>	BUS_IO_NOALIGN for the `alignment' argument.  Place the resulting
>	bus i/o address in `*portp'.  Map bus i/o space will be mapped,
>	and the resulting mapping placed in `*iohp'.  Returns zero
>	on success, non-zero on error.

>I don't currently have a need for the bus_io_alloc()/bus_io_free()
>functions, but the obvious use for them is the implementation of
>Plug N Play support.
>I have implemented these functions for the i386 port.
>Feedback is appreciated.  If there are no objections, I'll go ahead and
>commit the necessary changes to the i386 port late next week.

I just thought of something.

If the desired application of bus_io_{alloc,free}() is P&P I/O range
allocation, then bus_io_alloc() needs three more pieces of

1) minimum address (port)
2) maximum address (port)
3) number of address bits decoded (10 or 16)

The minimum and maximum addresses would also be useful for
bus_mem_alloc().  10-bit decoding is a silly ISA-bus artifact, so it's
only needed for I/O allocation.

BTW, how does your extent system handle 10-bit I/O decoding now?  Does
it just assume that any I/O port ranges in the [0,0x3ff] range use
10-bit decoding?
Mike Long <>     <URL:>
VLSI Design Engineer         finger for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil