From owner-cvs-all Wed Sep 29 4:37:15 1999 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8C7A515972; Wed, 29 Sep 1999 04:36:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from d219.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id VAA29920; Wed, 29 Sep 1999 21:36:48 +1000 Date: Wed, 29 Sep 1999 21:35:52 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Warner Losh Cc: "Matthew N. Dodd" , Takahashi Yoshihiro , kato@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, FreeBSD98-hackers@jp.freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/i386/conf files.i386 In-Reply-To: <199909290352.VAA08480@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Tue, 28 Sep 1999, Warner Losh wrote: > In message "Matthew N. Dodd" writes: > : If I understand you correctly you argue that both types of PIO access > : (normal and noncontig PC98) should use the method suggested for the PC98 > : case, namely that the eventual macro expend to: > : > : inb(regs[offset]) / outb(regs[offset], val) > > Actually, I think that he'd like to have everything precomputed in the > softc and use symbolic names. see sio for what I think he's saying. The symbolic names would change a little to names for indexes (register numbers). E.g., com->line_status_port would change to sc->sc_regs[COM_LSR] and all entries in sc->sc_regs[] would be initialised, not just the "optimised" ones. There would be no new macros; the old ones would be called with handle sc->sc_regs[REGNO] and offset 0. > : In the PC98 case we have to supply the length of the bus_space and a map > : describing the PIO offsets so we can compute each value of the array > : (regs[]). For the normal PIO bus_space we just fill out the array from > : base + 0 to base + len. The driver must build the register tables. This may be complicated and driver dependent for cases that really need indirection, but is trivial for the normal linearly addressed case. > I'm not sure I'd like requiring indirection in all cases... I can > have regions up to 256 registers (iirc) for pci (and eisa?) devices. > For these cases, simple addition seems better. Tables that large may cause too many cache collisions. I hope the indirect case is unusual for devices with lots of registers. > Right. However, if the config system gave the driver the bst and bsh > to use (never mind how for the moment), there would be no changes > needed to those drivers that used bus_space to work on those cards > that have creative mappings. The config system would somehow know > what that mapping is (maybe because the driver's probe or init routine > told it via a pc98_register_zone method (I'm making up the name as I'm > going along). The config system would then cache this information and > do a more complex version of what we're doing today with hints. That I think it's unreasonable for the config system to set up the mappings except the linear case. I've only been thinking of simple i/o routines. Routines like bus_space_read_region_1() probably need access to the register array so that they can step through it instead of using a constant step. Ugh. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message