From owner-freebsd-hackers Wed Jul 7 16: 6:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 36152154BC for ; Wed, 7 Jul 1999 16:06:49 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D771A78; Thu, 8 Jul 1999 07:06:48 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh Cc: Doug Rabson , hackers@freebsd.org Subject: Re: The busspace modernization initiative. In-reply-to: Your message of "Sun, 04 Jul 1999 15:57:52 CST." <199907042157.PAA44776@harmony.village.org> Date: Thu, 08 Jul 1999 07:06:48 +0800 From: Peter Wemm Message-Id: <19990707230648.D771A78@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message 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