Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jul 1997 21:51:35 +0200
From:      Stefan Esser <se@FreeBSD.ORG>
To:        Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc:        Michael Smith <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:  <19970730215135.03311@mi.uni-koeln.de>
In-Reply-To: <199707300552.HAA03429@labinfo.iet.unipi.it>; from Luigi Rizzo on Wed, Jul 30, 1997 at 07:52:58AM %2B0200
References:  <199707300600.PAA19038@genesis.atrad.adelaide.edu.au> <199707300552.HAA03429@labinfo.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 30, Luigi Rizzo <luigi@labinfo.iet.unipi.it> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970730215135.03311>