From owner-freebsd-current Sun Sep 5 6:29:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 82EA215002 for ; Sun, 5 Sep 1999 06:29:03 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id OAA00149; Sun, 5 Sep 1999 14:29:13 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 5 Sep 1999 14:29:13 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Mike Smith , John-Mark Gurney , "Zach N. Heilig" , freebsd-current@freebsd.org Subject: Re: PNP ids missing in sio.c In-Reply-To: <19990905122921.19EE11CA8@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 5 Sep 1999, Peter Wemm wrote: > Doug Rabson wrote: > > On Sat, 4 Sep 1999, Mike Smith wrote: > > > > > > > I'm curious what can be made of the PNP resource list we get from the B > IOS > > > > > at boot time... It lists motherboard resources too, we could probably > end > > > > > up with a fairly complete map of known resources to avoid. > > > > > > > > I bet we can roll another enumerator similar to pnp.c which takes the bio > s > > > > output and turns it into devices. It would mean removing all the probe > > > > hints from your kernel config to avoid confusion but apart from that it > > > > should work really well. > > > > > > This is one reason why I think that the PnP scan should be done > > > _before_ the legacy scan; there are cases where the legacy scan is > > > going to find stuff that the PnP enumerator also knows about. If the > > > PnP enumerator has already found it, then the legacy scan aborts; in > > > the reverse situation the PnP enumerator has no way of knowing that the > > > device has already been claimed. > > > > > > As for the BIOS PnP info; all I'm doing at the moment is scanning for > > > device and compat IDs. Since the information is formatted in exactly > > > the same fashion as ISA PnP data, I was hoping to actually dump the > > > current pointless scan and hook the BIOS access method into the new PnP > > > code. > > > > > > Another argument for making the PnP scan first is that the BIOS > > > identifies a whole pile of "do not go there" regions which you don't > > > want anything, even a legacy device probe, looking at. > > > > Its a difficult problem. If you run the heuristic probes first, then one > > of them might pick up a device intended for a pnp driver. On the other > > hand if you don't run the heuristic probes first, you have no idea what > > resource regions to avoid when allocating resources for pnp devices. > > > > Surely with a working pnpbios *all* devices become pnp devices which > > solves the problem quite neatly. > > One big problem that we see right now is best described with an example. > Suppose a system has a PnP soundblaster clone card. The BIOS configures > it at default settings. The user has a pcm0 at isa? foo. The ISA probe is > run first and "sees" the leftovers from the pnp bios and attaches. Later > the pnp probe runs and *moves* the pnp device out from underneath the isa > driver and reattaches it elsewhere. > > The "solution" that I see is for the isa probe to disable all the pnp > devices it can first before starting the isa device probe. Then the pnp > cards will be out of harms way while the isa probe runs and then can be > configured to work around the old-style isa cards. This would work well with the existing 'hardware' pnp driver since it supports disabling devices already. It would probably be good enough for a future pnpbios driver too. > > That means that the isa drivers won't be able to probe compatable pnp cards > that are just missing an ID match. I see the "solution" to that as an > override system that enables a user-defined ID match to be bound to an isa > device. Eg: specifically add (via userconfig-ng) PNP1234 to the pcm/sb > driver. This could be a bit tricky to get right but might work out for > legacy stuff with wierd ID's. This seems feasable. We will have to decide soon what this userconfig-ng thing will look like... -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message