Date: Thu, 08 Jul 1999 07:06:48 +0800 From: Peter Wemm <peter@netplex.com.au> To: Warner Losh <imp@harmony.village.org> Cc: Doug Rabson <dfr@nlsystems.com>, hackers@freebsd.org Subject: Re: The busspace modernization initiative. Message-ID: <19990707230648.D771A78@overcee.netplex.com.au> In-Reply-To: Your message of "Sun, 04 Jul 1999 15:57:52 CST." <199907042157.PAA44776@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
> In message <Pine.BSF.4.10.9907042236480.54036-100000@salmon.nlsystems.com> Do
ug Rabson writes:
> : This seems to bypass the nexus completely which isn't right. It wouldn't
> : detect conflicts between bus_space_alloc and the new-bus resource apis
> : since it has its own instances of struct rman.
>
> This is true. However, that's just because that was what the code
> that I acquired from the newconfig people did. I don't think that it
> must be this way.
At the very least it must use the real resource lists, not a second copy.
That probably means that nexus.c itself would have to export these functions.
> : Do we really need to
> : support this api for common newconfig style drivers?
>
> Yes. I believe that we do. One thing that this is used for is to map
> things, even if they conflict. I'm sure I understand why it does that
> beyond checks for conflicts/valid I/O addresses in some drivers
> (mostly the scsi drivers).
>
> I'll have to look into what this API is supposed to do.... It is
> definitely heavily used (or at least used in almost all) in the few
> drivers that I've tried to port over....
At the moment, the probe/attach routines use ia_iot from the aux arg:
struct isa_attach_args {
bus_space_tag_t ia_iot; /* isa i/o space tag */
bus_space_tag_t ia_memt; /* isa mem space tag */
bus_dma_tag_t ia_dmat; /* DMA tag */
isa_chipset_tag_t ia_ic;
int ia_iobase; /* base i/o address */
int ia_iosize; /* span of ports used */
int ia_irq; /* interrupt request */
int ia_drq; /* DMA request */
int ia_drq2; /* second DMA request */
int ia_maddr; /* physical i/o mem addr */
u_int ia_msize; /* size of i/o memory */
void *ia_aux; /* driver specific */
};
.. using the isa stuff for an example. (tough if they want multiple
IO ports per device, eh? like the keyboard controller at 0x60 and 0x64 with
another device in between...)
It uses the tag to get a handle:
if (bus_space_map(iot, ia->ia_iobase, SATLINK_IOSIZE, 0, &ioh))
return (0);
rv = 1;
ia->ia_iosize = SATLINK_IOSIZE;
ia->ia_msize = 0;
bus_space_unmap(iot, ioh, SATLINK_IOSIZE);
return (rv);
And uses the tag and handle in the bus_space_read/write_xxx() macros.
Under NetBSD/i386:
typedef int bus_space_tag_t;
typedef u_long bus_space_handle_t;
But NetBSD/Alpha:
typedef struct alpha_bus_space *bus_space_tag_t;
typedef u_long bus_space_handle_t;
struct alpha_bus_space {
/* cookie */
void *abs_cookie;
/* mapping/unmapping */
int (*abs_map) __P((void *, bus_addr_t, bus_size_t,
int, bus_space_handle_t *, int));
[..]
I don't see why we couldn't add a device_t pointer in there as well, and the
newconfig shim could use it to store the device_t of the wrapper device.
The bus_space_map() etc macros could then do the proper uplink calls to the
parent bus since it now has access to the device pointer.
> It doesn't change the fact that bus_space_hanle_t is supposed to be an
> opaque type and many places in the three don't treat it as such....
Yes, agreed there.
> Warner
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990707230648.D771A78>