Date: Wed, 30 Jul 1997 16:42:48 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: msmith@atrad.adelaide.edu.au, hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: Advice sought on PnP configuration Message-ID: <199707300712.QAA19565@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707300552.HAA03429@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 30, 97 07:52:58 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo stands accused of saying: > > Luigi Rizzo stands accused of saying: > > > > the driver. No manual configuration required (of course, the OS > > > must recognize your card, but that's another problem and is common > ... > > This information is also available from the ECSD, which can also only > > be fetched from the BIOS. > > wrong wording... I should have said "the OS must _know_ your card, or > how can it know that pnp_id 0x12345678 corresponds to the board "foo" and > must use driver "bar"... I was only referring to the resource information being available from the ECSD. > > > In order to configure cards correctly, the bios should know which > > > IRQs and which I/O address ranges are used by plain isa devices. > > > The former can be told to some bioses, the latter I have never seen > > > how to do on my systems. > > > > The former is available from the ECSD, the latter is specifically > > covered in the PnP specification. > > how ? I am talking about non-pnp devices... Have you read the PnP document from Microsoft? The procedure is explicitly detailed in the section on configuring cards. Basically, you configure the card such that it drives half its outputs low and expect to read 0x55 from all its ports, then swap to the other half of its outputs and expect to read 0xaa. If you don't read the right pattern from all the ports, there's something else there as well, so you relocate the card. > > My personal preference : > > > > - gather all the information : > > PCI probe > > PnP probe > > get ISA config (compiled in, datafile, etc.) > > get PCI/PnP identifier tables (compiled in, bootloader, etc.) > > unfortunately, in the current code, a device is probed and attached > right after the probe succeeds (otherwise, I guess one should store > information on which devices have been probed successfully and where... > etc) I appreciate this; I believe that the process should be changed. > > - walk ISA config data, probe possible devices > > We know which IRQ and I/O resources are still available, > > we can hunt for devices that match the gaps. > > but this is a problem: you cannot (generally) reprogram isa device, so > it would be better to probe them first and then relocate the > programmable ones at a later time. As I said, for PCI devices it is not > much of a problem: io addresses are generally taken from a different > range, DMA does not use the ISA dma controller, and interrupts can be > shared. But for PnP... You don't _want_ to reprogram an ISA device. You specifically _avoid_ them in the resource allocation for PnP and PCI devices by using the BIOS/chipset supplied resource information. Thus, when you get to the ISA probe stage, you know that resources allocated can't have ISA devices connected to them. > same goal that I have, but in a slightly different manner: step 2 > _disables_ all pnp devices so they cannot be recognised as legacy > devices. so the non-pnp isa attach cannot find PnP devices. As for > getting isa config info: the only way we can do it is by looking at > what devices have been successfully attached; compiled-in information > are not helpful when a kernel such as GENERIC is built, with a ton of > different devices compiled in. Disabling PnP devices, then probing and then assigning PnP devices later has the (dubious) advantage of helping bind ISA devices to assigned device names/numbers. I don't actually like this very much; the kernel configuration should do no more than enumerate the drivers which will be linked into the kernel; the drivers should then search for their devices using a set of "likely" resources. (Yes, defining "likely" is tough, but the information doesn't belong in the driver.) What I propose basically involves a "Poke and Pray" cycle after the "Plug and Play" process has inserted devices at known-safe locations; what the poking cycle is doing is prodding spaces that either have devices or are empty. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707300712.QAA19565>