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 to a device at port
address 0xCFB (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
_________________________________________________________________
Help STOP SPAM: Try the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
Followup to: <[email protected]>
By author: "fretre lewis" <[email protected]>
In newsgroup: linux.dev.kernel
> 1. which device is at port address 0xCFB?
Hopefully none.
> 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?
It's trying to verify that the PCI northbridge does *NOT* respond to
this (byte-wide) reference.
-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]>
Normally all accesses should be long (0xcf8/0xcfc) but x86 is byte addresseable and some chipsets do support byte accesses.
We do not encourage use of byte accesses as it will not be supported in future platforms.
Thanks,
Jun
> -----Original Message-----
> From: H. Peter Anvin [mailto:[email protected]]
> Sent: Wednesday, January 08, 2003 10:53 AM
> To: [email protected]
> Subject: Re: PCI code: why need outb (0x01, 0xCFB); ?
>
> Followup to: <[email protected]>
> By author: "fretre lewis" <[email protected]>
> In newsgroup: linux.dev.kernel
>
> > 1. which device is at port address 0xCFB?
>
> Hopefully none.
>
> > 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?
>
> It's trying to verify that the PCI northbridge does *NOT* respond to
> this (byte-wide) reference.
>
> -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]>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Nakajima, Jun wrote:
>
> Normally all accesses should be long (0xcf8/0xcfc) but x86 is byte addresseable and some chipsets do support byte accesses.
> We do not encourage use of byte accesses as it will not be supported in future platforms.
>
The PCI standard is quite explicit: byte accesses are permitted to the
data window (0xCFC) and not permitted to the address window (0xCF8).
Accepting byte accesses to the address window, or not supporting byte
accesses to the data window, *will* result in breakage (I can attest to
this fact quite well.)
-hpa
On 8 Jan 03 at 10:52, H. Peter Anvin wrote:
>
> > 1. which device is at port address 0xCFB?
>
> Hopefully none.
Actually I'm not sure. This code is here since at least 2.0.28,
and during googling I even found code for direct PCI access
(http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/gerald.zip/DIRECTNT.CPP?auto=CPP)
which sets lowest bit at 0xCFB to 1 before doing PCI config
accesses and reset it back to original value afterward.
So I believe that there were some chipsets (probably in 486&PCI times)
which did conf1/conf2 accesses depending on value of this bit.
Unfortunately I was not able to confirm this - almost nobody provides
northbridge datasheets from '94 era, even Intel does not provide them
(f.e. Neptune) anymore :-(
Best regards,
Petr Vandrovec
[email protected]
On Wed, 8 Jan 2003, Petr Vandrovec wrote:
> > > 1. which device is at port address 0xCFB?
> >
> > Hopefully none.
>
> Actually I'm not sure. This code is here since at least 2.0.28,
> and during googling I even found code for direct PCI access
> (http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/gerald.zip/DIRECTNT.CPP?auto=CPP)
> which sets lowest bit at 0xCFB to 1 before doing PCI config
> accesses and reset it back to original value afterward.
>
> So I believe that there were some chipsets (probably in 486&PCI times)
> which did conf1/conf2 accesses depending on value of this bit.
> Unfortunately I was not able to confirm this - almost nobody provides
> northbridge datasheets from '94 era, even Intel does not provide them
> (f.e. Neptune) anymore :-(
Fortunately that's not true. Grab the relevant docs from:
'ftp://download.intel.com/support/chipsets/430nx/'. The semantics of
0xcf8, 0xcf9, 0xcfa and 0xcfb I/O ports when used as byte quantities is
explained there. Note that 0xcf8 and 0xcfa are the way to get at the PCI
config space using conf2 accesses.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On 8 Jan 03 at 22:22, Maciej W. Rozycki wrote:
> On Wed, 8 Jan 2003, Petr Vandrovec wrote:
>
> > > > 1. which device is at port address 0xCFB?
> > >
> > > Hopefully none.
> >
> > Actually I'm not sure. This code is here since at least 2.0.28,
> > and during googling I even found code for direct PCI access
> > (http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/gerald.zip/DIRECTNT.CPP?auto=CPP)
> > which sets lowest bit at 0xCFB to 1 before doing PCI config
> > accesses and reset it back to original value afterward.
> >
> > So I believe that there were some chipsets (probably in 486&PCI times)
> > which did conf1/conf2 accesses depending on value of this bit.
> > Unfortunately I was not able to confirm this - almost nobody provides
> > northbridge datasheets from '94 era, even Intel does not provide them
> > (f.e. Neptune) anymore :-(
>
> Fortunately that's not true. Grab the relevant docs from:
> 'ftp://download.intel.com/support/chipsets/430nx/'. The semantics of
> 0xcf8, 0xcf9, 0xcfa and 0xcfb I/O ports when used as byte quantities is
> explained there. Note that 0xcf8 and 0xcfa are the way to get at the PCI
> config space using conf2 accesses.
Thanks, page 34 of 290479.pdf is exactly what I was looking for
(i.e. write 1 to 0xCFB to get PCI conf1, write 0 to get PCI conf2).
Next time I'll complain immediately instead of spending time with
browsing Intel website and google.
Thanks,
Petr Vandrovec
[email protected]
On Wed, 8 Jan 2003, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> >
> > Normally all accesses should be long (0xcf8/0xcfc) but x86 is byte addresseable and some chipsets do support byte accesses.
> > We do not encourage use of byte accesses as it will not be supported in future platforms.
> >
>
> The PCI standard is quite explicit: byte accesses are permitted to the
> data window (0xCFC) and not permitted to the address window (0xCF8).
> Accepting byte accesses to the address window, or not supporting byte
> accesses to the data window, *will* result in breakage (I can attest to
> this fact quite well.)
>
> -hpa
>
After power-on reset, or a hardware reset if provided (not SW
reset), you do a byte-write to CSE (Configuration Space Enable).
CSE is at 0xCF8. The 8-bit field is:
00000000B
| ||_________ SCE (special cycle enable)
| |__________ <1,3> Target function number
|_____________ non-zero = enable configuration
This is done by the BIOS because once the enable configuration bits
are set, all accesses are supposed to be 32 bits.
There is also another byte-port at 0xCFA this is called the
forward register and it must be set before enabling configuration
transactions. This register identifies one of 256 possible
PCI buses.
None of the 8-bit registers are supposed to be touched (they
are not accessible) after configuration transactions are
enabled. All of the configuration registers are specified
as numbered doubleword registers, from 0 to 15. Attempting to
read or write less than a doubleword can stop the bus interface
state-machine, locking up everything. This is because many of
the physical lines are shared (see IDSEL, muxed to address lines).
If the exact step-by-step bus activity for which it was designed,
does not occur, all bets are off!
This was hinted by "Nakajima, Jun" <[email protected]>.
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, 8 Jan 2003, Petr Vandrovec wrote:
> > Fortunately that's not true. Grab the relevant docs from:
> > 'ftp://download.intel.com/support/chipsets/430nx/'. The semantics of
> > 0xcf8, 0xcf9, 0xcfa and 0xcfb I/O ports when used as byte quantities is
> > explained there. Note that 0xcf8 and 0xcfa are the way to get at the PCI
> > config space using conf2 accesses.
>
> Thanks, page 34 of 290479.pdf is exactly what I was looking for
> (i.e. write 1 to 0xCFB to get PCI conf1, write 0 to get PCI conf2).
> Next time I'll complain immediately instead of spending time with
> browsing Intel website and google.
Well, the download.intel.com docs are sometimes hard to get by. There
are a few EISA and basic peripheral specs nearby, too.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +