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