Date: Thu, 11 Jan 1996 08:29:01 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: smpatel@wam.umd.edu, freebsd-hackers@FreeBSD.org, hasty@rah.star-gate.com, neil@synthcom.com, terry@lambert.org Subject: Re: PnP problem... Message-ID: <199601111629.IAA01989@freefall.freebsd.org> In-Reply-To: Your message of "Fri, 12 Jan 1996 00:13:41 %2B1100." <199601111313.AAA13705@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>The current order is: > >Probe and init PCMCIA >Probe and init EISA >Probe and init PCI >Probe and init ISA > >and the order in 2.1 was: > >Probe and init EISA This was a no-op in 2.1 since no drivers were supported by the old eisaconf code. >Probe and init ISA >Probe and init PCI > >>The only reason its in that order now is so that PCI/EISA devices that >>have an ISA compatibility mode are found by the PCI/EISA probes first. >>Neil's approach is more along the lines of how it should be, and the EISA >>code at least was written thinking that the attach of devices wouldn't >>necessarily follow the probe. > >Hmm. How do the ISA probes avoid rediscovering PCI/EISA devices? What >happens if there is a "bt0 at isa?" (as specified in the config) on the >ISA bus and another one on the PCI/EISA bus? I think this doesn't work >now. The only driver I know of that had this problem (the bt driver) handles it by keeping a static array of ioaddrs/found information and will not reprobe any conflicts. This should be moved to the configuration manager (as the XXX comments in bt.c say) as there are other adapters like the 3c509 that fall into this category. >If Neil's approach is used then the corresponding problems are: >How does the config manager know that some ISA devices are physically >the same as a PCI/EISA device? How does the config manager assign >minor numbers in the above complicated case involving bt0 and even in >simple cases? Simple. The PCI/EISA probe can tell you exactly where the PCI/EISA cards are in the system. These ioaddrs are removed from the address map the ISA portion of the bt driver presents to the configuration manager as the possible locations it could find a card before it does its probing. In the case of a card that has PnP ISA compatibility, the PnP code would either have to leave the card where it was, or change the PCI/EISA view of where the card is. I wouldn't expect this to ever be the case. >>3) Probe all ISA devices. A probe returns whatever information can >>be obtained non-invasively. ... > >That's almost no information. :-( Depends on the card. >>If a driver can't determine the I/O port, >>for example, it returns a map of all possible ports. > >0-0x3ff :-). I think ISA probes will have to be just as invasive as >now except they will be able to be more careful about clobbering >previously probed devices thanks to the more complete resource maps. Most cards I've used have at most 5 different port addresses a user can set. Some probes are non-invasive (only do reads), and these probes can return valuable information that reduces the number of possible conflicts during attach time. The point is that if you have good communication of all the information you know for sure about the system (from PCI/EISA and non-invasive ISA probes), then the likelyhood of something like the GENERIC kernel working for Joe user increases dramatically. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601111629.IAA01989>