Date: Mon, 21 Jul 1997 23:52:20 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Simon Shapiro <Shimon@i-connect.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pcireg.h lost children... ? Message-ID: <19970721235220.34651@mi.uni-koeln.de> In-Reply-To: <XFMail.970721141347.Shimon@i-Connect.Net>; from Simon Shapiro on Mon, Jul 21, 1997 at 11:06:22AM -0700 References: <19970718202558.63332@mi.uni-koeln.de> <XFMail.970721141347.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 21, Simon Shapiro <Shimon@i-Connect.Net> wrote:
> > Hmmm, why don't you probe for known vendor and device IDs ?
>
> I do. This is sort of sanity check. We se stray PCI cards that
> pretend to be what they are not (especially in prototypes).
> It may be unnecessary paranoia...
You are of course free to be as paranoid as you want to be :)
I've been accused of that too, on some occasions ...
> > One of the changes to the PCI code, that might follow (I have
> > not completely made up my mind) is, that the probe will just
> > associate a driver with a list of vendor/device IDs, and there
> > will no longer be a xxx_probe() function in the drivers.
>
> Hmmm... On this note, the DPT driver gets called with some Intel
> PCi devices on the motherboard that have no driver. If you enable
> the DPT_DEBUG_PCI option you see those.
Hmmm ? Sorry, I don't really understand what this means ...
The probe code of each driver will be called, until there is
one that claims to know the device with the given vendor and
device ID. There is no need for a chip-set driver, since the
chip-set better is completely configured before the system
even considers loading the primary boot sector.
I could suppress the "no driver" message for host bridges
and other chip-set components, and probably will do so some
time in the future, based on the class code. (In fact, there
will be a dummy default driver for the classes, which will
only be used, if no subdevice match (prefered) or chip ID
match (second) occured.)
Other than codes to the DPT's probe code (which should just
ignore devices that have unknown vendor/device IDs), there
should be no calls to the DPT driver from the PCI code.
> > One reason is that I want to be able to assign drivers to IDs
> > (chip or cards IDs) without recompilation.
>
> Sounds good. Will you not have to have a ``finite'' list of ``all''
> the drivers?
Well, in the end, we will. In the same sense as you could
build a complete list of Q-Bus or S-100 cards, today :)
Honestly: There are so many PCI chips that have gone through
several generations, and each one needed more IDs to be added
to the driver, but not much more code changes to just get it
to work. (Specific optimizations can wait ...)
> > The old approach caused trouble to people with NCR SCSI cards
> > based on new chips, which came with their own 4.xx BIOS, but
> > had the (inappropriate) 3.xx BIOS trying to initialize them.
>
> The DPT cards all report the same device ID. They are all compatible
> with each other. So it is even more sensible to remove this excessive
> testing.
How do you distinguish the different card versions, then ?
The device unique configuration space registers starting at
0x40 are a good place to put such information. Is this what
DPT does ?
> > > command = pci_conf_read(tag, PCI_COMMAND_STATUS_REG);
> > > if ( (command & PCI_COMMAND_MASTER_ENABLE) == 0 ) {
> > > printf("DPT: BUSMASTER disabled :-(\n");
> > > return (NULL);
> > > }
> >
> > I've never heard of a PCI BIOS, that failed to enable the
> > bus-master functionality, but did set up the chip correctly,
> > else. I really can't imagine a system that would trigger
> > this condition!
>
> Certain motherboards do not provide bus mastering on every slot.
Yes, true. Well, I'm wondering whether I should put a flag
into the pci_device struct that signals required features
to the PCI bus code, and one bit would indicate "this is a
bus-master card". Or I could provide a function that can be
called from the driver attach code, and which would perform
those tests, with no need for the driver to know about the
PCI command register and its bits.
(E.g. pci_check(tag, REQ_BUS_MASTER | REQ_MAP0 | REQ_MAP1)
which would signal success only if all the conditions are
simultanously fulfilled, and if for each map type the
appropriate access enable bit in the command register is
set. E.g. if map 0 was a memory map and map 1 ports, then
the above call would find this information in the map
registers, and it would check the enable bus-master bit
and the enable memory and enable I/O bit of the device
and all PCI to PCI bridges on the way to the CPU ...)
> > The other driver's don't test for the enable bits, and
> > just rely on the error indication returned by the call
> > to pci_map_XXX().
>
> It is doable. Am I violating the protocol by testing?
> Or is it just a waste? I had hard time when not ``getting''
> first. Got garbage back. Maybe it is working now...
Well, it definitely should work to just call the map
functions, and to try the alternate base register, if
the first one could not be mapped. If you have trouble
with this approach, then I'll have to fix the PCI code.
> > BTW: There appears to be a buglet in your code: Every
> > base address register may only hold either a memory or
> > a port address, and the address type is hard-wired into
> > the chip!
>
> Possible. This is still experimental. The DPT is supposed to
> be able to EITHER memory or I/O map the same registers.
This is true for quite a number of devices (e.g. the
NCR and Adpatec SCSI chips or the DEC Ethernet chips).
The port map should only be used from real-mode x86
code (DOS), which has no easy access to high memory ...
> > This means, that the use of base addr reg 0 for both the
> > call to pci_map_mem() and pci_map_port() must be wrong.
> > (I assume the letter is never tried, since the prior
^a (ahemm :)
> > always succeeds.)
>
> Actually, both succeed, if you arrange the code correctly.
Yes, they should, and a mapping that is not actually used
by the driver should not cause any harm. (The call to
pci_map_port is mostly a nop, if there are no conflicts,
while pci_map_mem creates a VM).
> The problem i am having is that memory mapping succeeds but
> nothing talks. I think I am after the wrong regions.
Hmmm, not knowing anything about the device, I can't offer
any advice ...
Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970721235220.34651>