Date: Mon, 02 Dec 2002 15:40:35 -0800 From: Peter Wemm <peter@wemm.org> To: Doug Rabson <dfr@nlsystems.com> Cc: Marcel Moolenaar <marcel@xcllnt.net>, Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 21719 for review Message-ID: <20021202234035.6BB862A8A8@canning.wemm.org> In-Reply-To: <200212020958.30876.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > On Sunday 01 December 2002 6:50 pm, Marcel Moolenaar wrote: > > 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=3D21719 > > > > > > > > Change 21719 by marcel@marcel_nfs on 2002/11/30 12:58:56 > > > > > > > > =09Remove isa and BOOTP_*. > > > > =09Comment out sio. > > > > > > > > =09The UART hardware is not supported by the sio driver. It is > > > > =09probed with some hackery, but the sio driver is in essense > > > > =09too 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. > > > > > 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. > > I'm sorry - I thought that the thing was converted to bus_space when it=20 > grew all the non-isa bus attachments. This really needs to happen to=20 > make the driver portable. I'm not sure what to do with the=20 > isa_irq_pending call - probably migrate it to the isa attachment. The division of labor is pretty broken the last time I checked. isa_irq_pending() is how bde checks that the interrupts are actually working on the isa bus. This stuff should be in sio_isa.c only, not in the common probe/attach routines. sio_pci.c should be able to say "trust me, it is irq N". Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20021202234035.6BB862A8A8>