Subject: Re: Proposed extension to bus.h interface
To: None <thorpej@nas.nasa.gov>
From: Mike Long <mike.long@analog.com>
List: tech-kern
Date: 08/15/1996 18:25:02
>From: Jason Thorpe <thorpej@nas.nasa.gov>
>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
information:

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 <mike.long@analog.com>     <URL:http://www.shore.net/~mikel>
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil