From owner-freebsd-hackers Wed Jul 30 12:51:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA28731 for hackers-outgoing; Wed, 30 Jul 1997 12:51:57 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA28712; Wed, 30 Jul 1997 12:51:52 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-2.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA20092 (5.67b/IDA-1.5); Wed, 30 Jul 1997 21:51:38 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id VAA12710; Wed, 30 Jul 1997 21:51:36 +0200 (CEST) X-Face: " Date: Wed, 30 Jul 1997 21:51:35 +0200 From: Stefan Esser To: Luigi Rizzo Cc: Michael Smith , hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: Advice sought on PnP configuration References: <199707300600.PAA19038@genesis.atrad.adelaide.edu.au> <199707300552.HAA03429@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707300552.HAA03429@labinfo.iet.unipi.it>; from Luigi Rizzo on Wed, Jul 30, 1997 at 07:52:58AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 30, Luigi Rizzo wrote: > > 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) The PCI probe/attach being combined is one of the shortcomings of the PCI code in 2.x. This was one of the reasons to rewrite the PCI code from scratch. The code as currently commited contains quite some compatibility wrappers, which hide the differences to the drivers, since I did not want them to diverge from 2.x too much, right now. > > - attach PCI devices > > I/O ports and IRQs are assigned by the PCI rules. > > - attach PnP devices > > IRQs are taken from the free pool left after PCI assignment and > > those marked for 'legacy' use. I/O ports are probed as per the > > PnP spec. > > - 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... > > I think it's important to leave the 'legacy' devices until _last_, as > > this prevents a PnP device being accidentally recognised as a 'legacy' > > device. > > 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. You could do PCI probe, ISA PnP Probe, config, PCI attach, ISA probe and attach (with PnP devices disabled) and finally PnP attach. But I think it would be sufficient to do it in the order: PCI probe, PnP probe, config (incl. disable non-PnPP devices that conflict with ISA PnP devices, if desired), attach PCI, attach PnP and finally probe and attach ISA. Regards, STefan