Date: Fri, 12 Sep 1997 13:35:29 +1000 From: Mike Smith <mike@smith.net.au> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: mike@smith.net.au (Mike Smith), gurney_j@resnet.uoregon.edu, perhaps@yes.no, freebsd-hackers@freebsd.org Subject: Re: PnP support Message-ID: <199709120335.NAA01011@word.smith.net.au> In-Reply-To: Your message of "Thu, 11 Sep 1997 17:24:55 %2B0200." <199709111524.RAA00618@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> Let me edit this slightly... > > > The most succinct extract I have on the "new" model reads : > > > > ---8<---snip---8<--- > > > > - gather all the information : > > PCI probe > > i.e. trust what the PCI bios says ? Yes. > > PnP probe > > get ISA config (compiled in, datafile, etc.) > > this means probe the isa devices and trust what the config info > say. At this point we have already effectively allocated 'extents' > for legacy ISA devices. No, this means read the compiled in hints for brute-force ISA probes. In the gather phase, we do *nothing* with the hardware that might cause any sort of confusion. PCI probe : get configuration from PCI BIOS. PnP probe : select all PnP devices, read config data, take off the bus. ISA probe : read compiled-in hints table > > get PCI/PnP identifier tables (compiled in, bootloader, etc.) > > this looks like a second-level probe for these devices: those not No. This is "read the tables that map PCI/PnP vendor/device numbers to driver names". Nothing more. > recognised by PCI/PnP drivers will be used as ISA ones ? Wouldn't > it make more sense to merge this step with the PCI and PnP probe, > so that devices recognized as PCI/PnP can be left with some degree > of freedom in reallocating resources, whereas others get fixed > resources ? We haven't touched resource allocation at this point. > Also, while we are on the subject: some legacy ISA device also have > software-configurable resources such as DMA or IRQ channels. methods > are device-specific (pre-PnP). In the case of the 3c509, for example, you have a "pseudo-PnP" probe for it which would run just after the "real" PnP probe. As long as the "smart" probe can provide the basic information required to configure the hardware and select a driver, it qualifies as PnP. > In other words, in this first 'probe' phase we end up with some > resources which are bound to a given value, and other which might > be assigned from a set of alternatives. No. We end up with a list of available resources (produced by the bus code) and a list of potential requirements (established by the gather process). > ALLOCATE: > Before going on with the attach, we have to take a decision among > the available options and then just go on with the attach routines, > marking those devices which could not be allocated the requested > resources ? Allocation occurs in stages, based on presence and preference. For PCI devices, the device is alreay present by virtue of configuration by the PCI BIOS, and so resources are directly allocated. PnP devices have preferences, and thus resources are allocated to them based on the "most preferable" selection. "most preferable" can be computed from the space left after PCI allocation, and by (where possible) avoiding resources requested by other (ISA) probes. Note that the PnP spec allows us to guarantee that we will not be sitting down on top of a non-PnP ISA device's I/O space, so we don't have to worry about avoiding ranges requested by ISA probes. > > - 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. > > here if some attach fails we can free the resources which have been > allocated for them, and possibly go back to ALLOCATE: if any device was > left out ? There should be no need for this; resources would only be considered to have been allocated if the attach succeeded. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120335.NAA01011>