[PATCH 03/11] x86/dtb: Add a device tree for CE4100
Mitch Bradley
wmb at firmworks.com
Tue Nov 30 08:32:14 EST 2010
On 11/29/2010 10:44 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2010-11-29 at 10:32 -1000, Mitch Bradley wrote:
>> 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.
That seems fine to me. It's not important that PCI be directly attached
to the root bus. I was mostly concerned about the relative positions of
ISA and PCI.
>
> 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.
>
>> 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.
>
>> 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 at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
More information about the devicetree-discuss
mailing list