Date: Fri, 13 Oct 1995 18:16:36 +0000 From: Matt Thomas <matt@lkg.dec.com> To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org Subject: Re: IPX now available Message-ID: <199510131816.SAA24191@whydos.lkg.dec.com> In-Reply-To: Your message of "Fri, 13 Oct 1995 11:19:51 MST." <199510131819.LAA17947@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199510131819.LAA17947@phaeton.artisoft.com>, Terry Lambert wrote:
> > Actually, I'd rather not have to have all of the IRQ, DRQ, ports, etc
> > determined during probe. Look at EISA or PCI devices... the probe is
> > a non-intrusive determination if a card is present and what driver may
> > be apporpriate for that device. The IRQ, DRQ, and port range determination
> > should only happen after we know that we have something worth talking to
> > (ie the probe is successfull). This works so long as we allow attaches
> > to fail (which they could for other reasons like insufficient memory).
> > I'd rather design the system to look like:
> >
> > probe ()
> > {
> > minimum to determin presence of hardware
>
> AND determine the allowable ranges for IRQ/DRQ/IO/memory this device
Agreed. The probe routine should allocate no resources (such as VM) and
no local state (ie. no private information for the driver's attach
routines). It only provides information to configuration manager about
the number of devices, and the ranges for the device. Note that for IRQ
that not only the values should be supplied, but the types of IRQ that
are supported (level, edge) as well.
Either via a smarter bootloader or a VM86 mode, calls into the BIOS
to get configuration information should be done as well. For instance,
getting the information out of the EISA CMOS should the DEPCA driver
since the DE422 config registers are write-only.
Also, the probe needs to be done once on a per bus-type basis;
a probe should never try to all the different bus types at once.
For PCI, I'm beginning in favor of having the driver call a pci_match
routine to find instances of itself instead of the currently "passive"
method. The passive method just doesn't lend itself to LKM. One other
reason I favor it is so that I could have a "generic" DC21x4X module
and then have various board/chip specific LKMs. The de driver is getting
fairly large and I'd like a method to trim out the unneeded code.
> > }
>
> meta_attach()
> {
> create a graph of "least relocatable" to "most relocatable"
> determine desirable "location freeze" for each device
> call per device attach with location information
On the pci-sig mailing list, it seems many BIOS makers are putting in
a Micro$oft configuration mode which only configurations "boot" devices
and then expects the PnP O/S to call into the PCI BIOS to finish
configuring all the other devices.
For PnP devices that need configuring, the meta_attach is responsible
for setting them to the proper drq/irq/port/memory/etc.
> }
>
> >
> > attach()
> > {
At this point in time, the configuration manager should have assigned
(either dynamically if needed or statically if required) the port address,
IRQ, and memory (and any other bus-specific resources). The driver should
not have to pick anything at this point.
> > Determin port Addresses
At this point, the only the driver can do is either verify that the
device exists at this address and is setup correctly.
> > if (!reserve port address) {
> > return some error code
> > }
> > Determine IRQ
> > if (!Map IRQ Handler) {
> > release port address
Only if said port address was dynamically assigned to the device,
if the port (or memory) address is fixed then that address should
not be released.
Note that if there was a conflict, the configuration manager should
have never bothered to call the attach routine.
> > return some error code
> > }
> > Register other resources...
> > Setup the card for work
> > Enable interrupts
> > return success
> > }
> >
> > The new EISA code will follow this approach.
>
> As should PCI, PCMCIA, and ISA if mapped using a PCI<->ISA bridge (ie: PCI
> is the primary bus, ISA is the secondary).
>
> The caveat on destructive probes (those involving triggering of interrupts,
> like IN/Lance ethernet, etc.) is that they must be prevented.
>
> A destructive probe should be limited to a "add hardware mode". Just like
> Windows 95: a user triggered event or an install triggered event that does
> not repeat each boot.
In my mind, if a user configures a device (such the probe and/or meta_attach
is bypassed) and then the attach routine is called, the attach is allowed
to do the equivalent of a destructive probe since it unconditionally owns
those resources.
----
The database created by the configuration manager and filled in by the probes
and refined by the meta_attaches must be non-volatile and independent of the
kernel. Note that this means that either the resource information in the
config file disappears or config will need to able to write out a resource
database file.
The boot loader will need to able to read this configuration database and
put it into memory along side the kernel image. Userconfig could then
either stay in the kernel or become a separate entity. Actually, it might
even make sense for userconfig to become the second-stage loader since it
will have the proper information to do it.
Matt Thomas Internet: matt@lkg.dec.com
3am Software Foundry WWW URL: <currently homeless>
Westford, MA Disclaimer: Digital disavows all knowledge
of this message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510131816.SAA24191>