Date: Sun, 5 Sep 1999 14:29:13 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@netplex.com.au> Cc: Mike Smith <mike@smith.net.au>, John-Mark Gurney <gurney_j@resnet.uoregon.edu>, "Zach N. Heilig" <znh@thequest.net>, freebsd-current@freebsd.org Subject: Re: PNP ids missing in sio.c Message-ID: <Pine.BSF.4.10.9909051427050.2081-100000@salmon.nlsystems.com> In-Reply-To: <19990905122921.19EE11CA8@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9909051427050.2081-100000>