Date: Tue, 28 Sep 1999 21:52:31 -0600 From: Warner Losh <imp@village.org> To: "Matthew N. Dodd" <winter@jurai.net> Cc: Bruce Evans <bde@zeta.org.au>, 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: <199909290352.VAA08480@harmony.village.org> In-Reply-To: Your message of "Tue, 28 Sep 1999 21:02:38 EDT." <Pine.BSF.4.10.9909282058160.1659-100000@sasami.jurai.net> References: <Pine.BSF.4.10.9909282058160.1659-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909290352.VAA08480>