On Mon, 2010-11-29 at 10:32 -1000, Mitch Bradley wrote:
quoted text
> The usual layout is that the PCI bus is a direct child of
> the root node, and the ISA bus is a child of the PCI bus.

Right, tho we have been relaxing that on SoC for some time now, at least
on powerpc, since the PCI bus itself tend to hang off one of the SoC
internal busses (as a sibling of other busses) and that those tend to be
represented in the tree, so we make PCI be a child of that SoC bus.

This is also useful in the case where you have multiple SoCs (some are
capable of SMP interconnects) in which case you really have multiple
separate PCI busses and it's clearer to have each of them be the child
of its own SoC node.

quoted text
> That reflects the "Northbridge + Southbridge" wiring that
> was common at the time that PCI was first introduced.
> It's usually the case that faster and wider buses are closer
> to the root, with speed and address width decreasing as you
> go away from the root.
>
> The fact that PCI configuration accesses are done via I/O
> port 0x3fc doesn't make it a child of the ISA bus, because
> I/O space is inherent in the x86 CPU architecture and thus
> can be considered to be part of the root address space.
> 
> In the systems that I have worked with, the ISA bridge is a
> first-class PCI device with a PCI config header, so it fits
> naturally underneath the PCI bus.

This is actually the case of most systems, tho those Atoms SoC are a bit
weird as, afaik, they don't really have PCI... they just simulate some
kind of PCI config space for on-chip devices ,at least that's my
understanding.

Sebastian, do you have a block diagram of the SoC ? Following the actual
bus hierarchy of the chip might be the best approach.

Cheers,
Ben.

quoted text
> Here are the properties for PCI and ISA on the OLPC XO-1.5
> platform (Via C7 x86 CPU with Via VX855 IO chip):
> 
> 
> ok dev /pci
> ok .properties
> interrupt-map            00000800 00000000 00000000 00000001 ff86bf34 0000000a 00000000
>                          00006000 00000000 00000000 00000001 ff86bf34 0000000a 00000000
>                          00008000 00000000 00000000 00000001 ff86bf34 0000000a 00000000
>                          00008100 00000000 00000000 00000002 ff86bf34 00000009 00000000
>                          00008200 00000000 00000000 00000003 ff86bf34 0000000b 00000000
>                          00008400 00000000 00000000 00000004 ff86bf34 0000000a 00000000
>                          0000a000 00000000 00000000 00000001 ff86bf34 00000009 00000000
> interrupt-map-mask       0000ff00 00000000 00000000 00000007
> #interrupt-cells         00000001
> slot-names               00000000
> slave-only               00000000
> clock-frequency          01fca055
> bus-range                00000000 00000000
> #size-cells              00000002
> #address-cells           00000003
> device_type              pci
> name                     pci
> 
> ok dev /pci/isa
> ok .properties
> devsel-speed             00000001
> class-code               00060100
> subsystem-vendor-id      0000152d
> subsystem-id             00000833
> max-latency              00000000
> min-grant                00000000
> revision-id              00000000
> device-id                00008409
> vendor-id                00001106
> interrupt-parent         ff86bf34
> #interrupt-cells         00000002
> ranges                   00000000 00000000 02000000 00000000 00000000 01000000
>                          00000001 00000000 01000000 00000000 00000000 00010000
> clock-frequency          007ea5e0
> reg                      00008800 00000000 00000000 00000000 00000000
> #size-cells              00000001
> #address-cells           00000002
> device_type              isa
> name                     isa
> 
> Note that the PCI node has no reg property.  On a system with multiple independent PCI buses at the top level, it would be necessary to distinguish them with reg properties reflecting their different addresses in the root address space.  PC-style architectures typically (always?) have a single top-level PCI domain, so I've never never needed to do that in x86 land.  It used to be pretty common on PPC "big iron".
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/