Date: Sun, 01 Dec 2002 20:46:07 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcel@xcllnt.net Cc: dfr@nlsystems.com, perforce@freebsd.org Subject: Re: PERFORCE change 21719 for review Message-ID: <20021201.204607.91990973.imp@bsdimp.com> In-Reply-To: <20021201185017.GA4331@dhcp01.pn.xcllnt.net> References: <200211302059.gAUKxkZZ077084@repoman.freebsd.org> <200212011011.33999.dfr@nlsystems.com> <20021201185017.GA4331@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021201185017.GA4331@dhcp01.pn.xcllnt.net>
Marcel Moolenaar <marcel@xcllnt.net> writes:
: On Sun, Dec 01, 2002 at 10:11:33AM +0000, Doug Rabson wrote:
: > On Saturday 30 November 2002 8:59 pm, Marcel Moolenaar wrote:
: > > http://perforce.freebsd.org/chv.cgi?CH=21719
: > >
: > > Change 21719 by marcel@marcel_nfs on 2002/11/30 12:58:56
: > >
: > > Remove isa and BOOTP_*.
: > > Comment out sio.
: > >
: > > The UART hardware is not supported by the sio driver. It is
: > > probed with some hackery, but the sio driver is in essense
: > > too ISA/i386 oriented (pretty much like fb/vga/sc).
: >
: > In what way?
:
: It assumes the UART uses I/O. The isa_irq_pending() function is also
: an example of an ISA dependency. The latter does not prevent the sio
: driver from working, but it does cause an annoying message at boot.
There's no ISA bus at all, or there's no ISA expansion slots?
: > The sio driver itself just assumes that it can use
: > bus_space to access a standard 16550 uart or similar. The bus
: > attachment code (sio_isa, sio_pccard, sio_ebus etc.) contains any code
: > which is bus-related. This driver works quite well on five different
: > busses - what does the HP machine do that is different?
:
: For one, it hasn't got any ISA busses. Secondly, the Diva comm board
: is memory mapped. In sioprobe() we assume I/O. It's also a multiport
: board and we also don't seem to have the framework yet to just tell
: it the characteristics of this board as the Linux driver has.
It would be trivial to hack the sio driver to do memory mapped I/O,
but that's more in the realm of the puc driver. puc handles
multi-ported boards and uses a lookup table it has to tell the sio
driver what kind of stuff to do.
These are nits, not major reasons to avoid sio.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021201.204607.91990973.imp>