hi,
first, I have to say sorry for my 10th posting the same question , I hope
someone can answer it indeed, it seem too difficult for me.
I am learning code pci_check_direct(), at arch/i386/kernel/pci-pc.c
the PCI spec v2.0 say: ( page32)
"Anytime a host bridge sees a full DWORD I/O write from the host to
CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS
register. On full DWORD I/O reads to CONFIG_ADDRESS,the bridge must return
the
data in CONFIG_ADDRESS. Any other types of accesses to this
address(non-DWORD)
have no effect on CONFIG_ADDRESS and are excuted as normal I/O transaction
on PCI bus......"
CONFIG_ADDRESS = 0xCF8
CONFIG_DATA = 0xCFC
so I think "outb (0x01, 0xCFB);" just is a normal write operation to a
device at port address 0xCFB not a configuration type operation(maybe
wrong,fix me), then my questions are:
1. which device is at port address 0xCFB? (please note, NOT 0xCF8)
2. what is meaning of the writing operation "outb (0x01, 0xCFB);" for THIS
device?, it'seem that PCI spec v2.0 not say anything about it?
3. why need "outb (0x01, 0xCFB);" before configuration operation "outl
(0x80000000, 0xCF8);" if check configuration type 1? and why need "outb
(0x00, 0xCFB);" before "outb (0x00, 0xCF8);" if check configuration type 2?
please help me, thanks a lot.
406 static struct pci_ops * __devinit pci_check_direct(void)
407 {
408 unsigned int tmp;
409 unsigned long flags;
410
411 __save_flags(flags); __cli();
412
413 /*
414 * Check if configuration type 1 works.
415 */
416 if (pci_probe & PCI_PROBE_CONF1) {
417 outb (0x01, 0xCFB); <<<=========
418 tmp = inl (0xCF8);
419 outl (0x80000000, 0xCF8);
420 if (inl (0xCF8) == 0x80000000 &&
421 pci_sanity_check(&pci_direct_conf1)) {
422 outl (tmp, 0xCF8);
423 __restore_flags(flags);
424 printk(KERN_INFO "PCI: Using configuration type
1\n");
425 request_region(0xCF8, 8, "PCI conf1");
426 return &pci_direct_conf1;
427 }
428 outl (tmp, 0xCF8);
429 }
430
431 /*
432 * Check if configuration type 2 works.
433 */
434 if (pci_probe & PCI_PROBE_CONF2) {
435 outb (0x00, 0xCFB); <<<=========
436 outb (0x00, 0xCF8);
437 outb (0x00, 0xCFA);
438 if (inb (0xCF8) == 0x00 && inb (0xCFA) == 0x00 &&
439 pci_sanity_check(&pci_direct_conf2)) {
440 __restore_flags(flags);
441 printk(KERN_INFO "PCI: Using configuration type
2\n");
442 request_region(0xCF8, 4, "PCI conf2");
443 return &pci_direct_conf2;
444 }
445 }
446
447 __restore_flags(flags);
448 return NULL;
449 }
450
451 #endif
_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail
> 1. which device is at port address 0xCFB? (please note, NOT 0xCF8)
0xcfb ('bee') is the fourth byte of the 32 bit register that sits/starts
at 0xcf8 ('eight'). Note the difference in the code between the outb and
outl calls.
To answer your other questions, I think you'd have better luck reading
the spec for the x86 pc-style PCI bridge chip, rather than the (generic)
PCI v2.0 spec itself. The spec for the actual chip is always the final
authority for what's going on. (Unless, of course, it's wrong...)
Ray
On 8 Jan 2003, Ray Lee wrote:
> > 1. which device is at port address 0xCFB? (please note, NOT 0xCF8)
>
> 0xcfb ('bee') is the fourth byte of the 32 bit register that sits/starts
> at 0xcf8 ('eight'). Note the difference in the code between the outb and
> outl calls.
>
> To answer your other questions, I think you'd have better luck reading
> the spec for the x86 pc-style PCI bridge chip, rather than the (generic)
> PCI v2.0 spec itself. The spec for the actual chip is always the final
> authority for what's going on. (Unless, of course, it's wrong...)
>
> Ray
>
The problem is that he's discovered something that's not supposed
to be in the code. Only 32-bit accesses are supposed to be made to
the PCI controller ports. He has discovered that somebody has made
some 8-bit accesses that will not become configuration 'transactions'
because they are not 32 bits. According to the spec, such accesses
become direct I/O to some underlying device. So, if some underlying
device shares the same I/O address space as the PCI device, that
machine is broken.
FYI, the mechanism by which ix86 hardware determines if the PCI
port access is a configuration read or configuration write is
the 32-bit access. Any other access cannot be interpreted by
the hardware as a configuration transaction. (Page 321.,
"Into to configuration Mechanisms", PCI System Architecture,
ISBN 0-201-30974-2)
It is possible that somebody had a bad board and found that writing
some junk to this port 'fixed' something. If this is so, then the
code needs some comments. Otherwise, the non-32bit accesses should
be removed.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Wed, 2003-01-08 at 10:49, Richard B. Johnson wrote:
> The problem is that he's discovered something that's not supposed
> to be in the code. Only 32-bit accesses are supposed to be made to
> the PCI controller ports.
<shrug> Okay, I withdraw my interpretation. Since I had to rewrite
arch/ppc/kernel/qspan_pci.c recently, I felt mildly qualified to offer
an opinion, but obviously I was wrong :-).
Ray
Followup to: <[email protected]>
By author: "Richard B. Johnson" <[email protected]>
In newsgroup: linux.dev.kernel
>
> The problem is that he's discovered something that's not supposed
> to be in the code. Only 32-bit accesses are supposed to be made to
> the PCI controller ports. He has discovered that somebody has made
> some 8-bit accesses that will not become configuration 'transactions'
> because they are not 32 bits.
>
Right. That's what the code is checking for.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On 8 Jan 2003, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: "Richard B. Johnson" <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > The problem is that he's discovered something that's not supposed
> > to be in the code. Only 32-bit accesses are supposed to be made to
> > the PCI controller ports. He has discovered that somebody has made
> > some 8-bit accesses that will not become configuration 'transactions'
> > because they are not 32 bits.
> >
>
> Right. That's what the code is checking for.
>
> -hpa
Somebody is very lucky the designer of the bus interface state-machine
let him get away with it. This is a borderline "insane instruction" that
could, on some (future?) machine, require a power-off to recover. This is
NotGood(tm). It's like testing a fuse by shorting out a circuit. If it
works, the circuit no longer works. If I doesn't, the circuit no longer
works. Some things should not be tested.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
Richard B. Johnson wrote:
> On 8 Jan 2003, H. Peter Anvin wrote:
>
>
>>Followup to: <[email protected]>
>>By author: "Richard B. Johnson" <[email protected]>
>>In newsgroup: linux.dev.kernel
>>
>>>The problem is that he's discovered something that's not supposed
>>>to be in the code. Only 32-bit accesses are supposed to be made to
>>>the PCI controller ports. He has discovered that somebody has made
>>>some 8-bit accesses that will not become configuration 'transactions'
>>>because they are not 32 bits.
>>>
>>
>>Right. That's what the code is checking for.
>>
>> -hpa
>
> Somebody is very lucky the designer of the bus interface state-machine
> let him get away with it. This is a borderline "insane instruction" that
> could, on some (future?) machine, require a power-off to recover. This is
> NotGood(tm). It's like testing a fuse by shorting out a circuit. If it
> works, the circuit no longer works. If I doesn't, the circuit no longer
> works. Some things should not be tested.
>
If so, we will get an bug report rather than mysterious strange
behaviour. This is a good thing. (Amusingly enough, exactly this code
in the Linux kernel actually found a bug in one of the very early
versions of the Transmeta northbridge. It was fixed in firmware.)
-hpa