Date: Mon, 21 Jul 1997 11:06:22 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Stefan Esser <se@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: pcireg.h lost children... ? Message-ID: <XFMail.970721141347.Shimon@i-Connect.Net> In-Reply-To: <19970718202558.63332@mi.uni-koeln.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Stefan Esser; On 18-Jul-97 you wrote:
> On Jul 17, Simon Shapiro <Shimon@i-Connect.Net> wrote:
> [ ... new macro names for PCI classes and config register bits ... ]
> > It did, for a while, break compatability...
>
> Well, I'm sorry for that.
> But I did not expect drivers to actually use those names ...
Normal, routine, to be expected... :-)
> And you were warned: I left no doubt in my commit messages,
> that the new PCI code was a independent implementation :)
Ah...
...
> 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...
> 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.
> 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?
...
> 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.
>
> > 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.
...
> 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...
> You should not check those values from within any driver,
> IMHO, but instead just try to map the regions you need,
> and perform an error exit if mandatory mappings failed.
OK. We will try...
> 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 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
> always succeeds.)
Actually, both succeed, if you arrange the code correctly.
The problem i am having is that memory mapping succeeds but
nothing talks. I think I am after the wrong regions.
Still under investigation.
> The PCI BIOS needs the type bits (low order bits of the
> address base registers) to be R/O in order to assign valid
> addresses. If both memory and port accesses are supported,
> then one register will have the two low order bits wired
> to 01, and another one will have low order 4 bits of 0000
> (or less likely some other even number).
>
> The PCI BIOS uses the low order bits to decide whether
> some currently unused port or memory region is reserved
> for that chip, and then puts the base into the register.
>
> You know from the data sheet, which register will hold
> a port and which one will hold a memory address, if they
> can be assigned.
>
> BTW: Your test of the memory and port enable bits is not
> sufficient, if the devices are behind a PCI to PCI bridge,
> as Justin Gibbs pointed out to me. (And I'll modify the
> PCI code to correctly return an error indication to the
> pci_map_xxx() call, in such a case.)
I am learning about the nasty side of PCI-PCI bridges every day...
Thanx for the help.
Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970721141347.Shimon>