From owner-cvs-all Tue Sep 28 20:52:59 1999 Delivered-To: cvs-all@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id DE5EF14E6B; Tue, 28 Sep 1999 20:52:38 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA32845; Tue, 28 Sep 1999 21:52:29 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA08480; Tue, 28 Sep 1999 21:52:31 -0600 (MDT) Message-Id: <199909290352.VAA08480@harmony.village.org> To: "Matthew N. Dodd" Subject: Re: cvs commit: src/sys/conf files src/sys/i386/conf files.i386 Cc: Bruce Evans , Takahashi Yoshihiro , kato@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, FreeBSD98-hackers@jp.freebsd.org In-reply-to: Your message of "Tue, 28 Sep 1999 21:02:38 EDT." References: Date: Tue, 28 Sep 1999 21:52:31 -0600 From: Warner Losh Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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. : 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. 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. : This would make the bus_space_{read,write} calles the same for the PC98 : case and the normal PIO case and would, I believe, require no other : driver/consumer changes save in the PC98 case which would require the : setup to supply the offset map. Right? 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 would allow the pc98 attachments to behave almost like ISA. I've not put pen to paper on a design or code on how this would work exactly. These are just thoughts I've had while contemplating how to expand the bus_space system to deal with the strange mappings that are present in a pc98 machine. I get a little fuzzy on this part of the system sometimes, but I think that's what the middle levels are for. Anyway, just thinking out loud. My goals are certainly slanted towards maintainability of code over extreme optimization. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message