[ Lenghty treatment on how things probably work, without
  any warranty on correctness -- especially on the 386
  parts. ]

> Izumi Tsutsui wrote:
> > Maybe difference between physical and logical structures, as Allen said.

A brief look at arch/x86/pci/pci_machdep.c suggests the main
difference between PCI on x86 and powerpc/ibm4xx is that on
the PC, there is a canonical way of accessing the configuration
space (four IO registers at fixed address).

Hence on the x86, it is possible to iterate PCI bus without
any setup. The mainbus is thus able to construct meaningful
attach arguments to the pci/pci.c and let it do its job
(see below on bus_space tags).

The 4xx, on the other hand, accesses PCI configuration space
via memory mapped registers -- so in order to talk to the
bus, it needs to map these registers first.

Other thing is relation between PCI's view of the address
space and ${local bus}'s -- there's no reason to 'a priori'
assume ${lb} and PCI addresses are 1:1! The pchb on 4xx needs
to be first configured so that it knows which PCI address
ranges to forward to which PLB address ranges. Since the 4xx
doesn't have any "natural" IO bus, the pchb fakes one
(remember: PCI has separate transactions for memory and IO
transfers) via another configurable memory range -- accesses
to this window will "magically" generate PCI IO cycles instead
of memory cycles.

The PC _probably_ just maps memory and PCI addresses 1:1
somewhere in the chipset, w/o requiring any setup. The
mainbus code can pass regular memory and i386 IO bus_space
tags to MI pci and it just works.

And like Allen, I believe internally the 386 has a regular
high speed memory bus, to which actual PCI bridge is connected.
I'm quite confident no sane engineer would use PCI as primary
memory bus for his CPU -- 1. it's slow as hell, 2. needs to
be configured before one can use it. ;-)

> >>From software view, the PCI bridge can be seen via PCI configuration
> > space. It's a logical "PCI-HOST bridge" PCI device.
> > On real hardware, the PCI bridge is located on CPU local bus.
> > While it's called "pchb" on evbppc, it isn't the same device
> > with the former PCI-HOST bridge device seen via PCI, but a bus
> > controller attached to the local bus.

Hmm, I think they're pretty much the same, see also below. As I
understand it, "PCI host bridge" == "PCI-to-${whatever} bridge
that on given system is used to configure the PCI bus" (eg. initiates
configuration cycles for given segment).

> Ok. Since there are some redundant codes in ibm4xx/pci and pchb
> driver, I want to bring a pchb matter upon again, and to confirm it.
> (Perhaps you may blame me that my confirmation is redundant... ;-) )

Yep, I agree the 4xx PCI code needs a cleanup.

> The following is a boot log of 405GPr machine:
> 
> pchb0 at plb0
> pchb0: IBM PPC 405GP PCI Bridge (rev. 0x21)
> pci0 at pchb0
> pci0: i/o space, memory space enabled
> IBM PPC 405GP PCI Bridge (host bridge, revision 0x21) at pci0 dev 0
>  function 0 not configured
> 
> The latter '405GP PCI Bridge' is a logical that you said.

No, it's the real, physical pchb itself. You're seeing it second
time because for the first time (pchb0) you we're looking at
its PLB end -- and now you've discovered its PCI end during
PCI bus enumeration :-).

> > We shouldn't call the latter one "pchb" to avoid confusion?
> > (on arc it's called "necpb" and on evbmips it's "aupci", I think)
> 
> Ok. I see. We should change a device name for it.
> What name is a proper name?
> I have no good idea for naming. ;-(

I don't see anything wrong with the name...

	-- Jachym

PS: Apologies for the length (and the content if it turns out
    to be nonsense...)