Date: Wed, 29 Sep 1999 21:35:52 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@village.org> Cc: "Matthew N. Dodd" <winter@jurai.net>, Takahashi Yoshihiro <nyan@FreeBSD.org>, 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 Message-ID: <Pine.BSF.4.10.9909292041010.11108-100000@alphplex.bde.org> In-Reply-To: <199909290352.VAA08480@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Sep 1999, Warner Losh wrote: > In message <Pine.BSF.4.10.9909282058160.1659-100000@sasami.jurai.net> "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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9909292041010.11108-100000>