Date: Sun, 05 Sep 1999 20:29:21 +0800 From: Peter Wemm <peter@netplex.com.au> To: Doug Rabson <dfr@nlsystems.com> 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: <19990905122921.19EE11CA8@overcee.netplex.com.au> In-Reply-To: Your message of "Sun, 05 Sep 1999 09:56:39 %2B0100." <Pine.BSF.4.10.9909050954220.2081-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
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?19990905122921.19EE11CA8>