From: Mitch Bradley <wmb@firmworks.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Scott Wood <scottwood@freescale.com>,
sodaville@linutronix.de,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
x86@kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/11] x86/dtb: Add a device tree for CE4100
Date: Mon, 29 Nov 2010 11:32:14 -1000 [thread overview]
Message-ID: <4CF41BDE.1030800@firmworks.com> (raw)
In-Reply-To: <1291063470.32570.312.camel@pasglop>
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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2010-11-29 21:32 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-25 17:39 Add device tree support for x86 Sebastian Andrzej Siewior
2010-11-25 17:39 ` [PATCH 01/11] x86/kernel: remove conditional early remap in parse_e820_ext Sebastian Andrzej Siewior
2010-12-08 8:38 ` [sodaville] " Sebastian Andrzej Siewior
2010-12-08 14:15 ` Thomas Gleixner
2010-12-15 23:28 ` H. Peter Anvin
2010-12-16 9:55 ` Sebastian Andrzej Siewior
2010-11-25 17:39 ` [PATCH 02/11] x86: Add device tree support Sebastian Andrzej Siewior
2010-11-25 22:53 ` Sam Ravnborg
2010-11-26 9:06 ` Sebastian Andrzej Siewior
2010-11-26 21:42 ` Benjamin Herrenschmidt
2010-11-28 13:49 ` Sebastian Andrzej Siewior
2010-11-28 22:28 ` Benjamin Herrenschmidt
2010-12-30 8:26 ` Grant Likely
2010-12-30 8:45 ` Rob Landley
2010-12-30 20:58 ` Grant Likely
2011-01-03 16:05 ` [sodaville] " H. Peter Anvin
2011-01-03 16:19 ` H. Peter Anvin
2011-01-03 17:52 ` Grant Likely
2011-01-03 18:06 ` H. Peter Anvin
2011-01-03 18:10 ` H. Peter Anvin
2010-12-30 20:57 ` Grant Likely
2010-12-31 0:51 ` [sodaville] " H. Peter Anvin
2010-11-25 17:39 ` [PATCH 03/11] x86/dtb: Add a device tree for CE4100 Sebastian Andrzej Siewior
2010-11-26 21:57 ` Benjamin Herrenschmidt
2010-11-28 16:04 ` Sebastian Andrzej Siewior
2010-11-28 22:53 ` Benjamin Herrenschmidt
2010-11-29 1:34 ` Mitch Bradley
2010-11-29 18:26 ` [sodaville] " H. Peter Anvin
2010-11-29 20:03 ` Benjamin Herrenschmidt
2010-11-29 19:44 ` Sebastian Andrzej Siewior
2010-12-02 0:40 ` David Gibson
2010-11-29 19:07 ` Scott Wood
2010-11-29 20:05 ` Benjamin Herrenschmidt
2010-11-29 20:32 ` Mitch Bradley
2010-11-29 20:44 ` Benjamin Herrenschmidt
2010-11-29 21:32 ` Mitch Bradley [this message]
2010-11-29 23:47 ` Alan Cox
2010-11-30 2:50 ` Benjamin Herrenschmidt
2010-11-30 11:20 ` Sebastian Andrzej Siewior
2010-11-29 23:42 ` Alan Cox
2010-11-30 21:18 ` [sodaville] " H. Peter Anvin
2010-11-30 11:51 ` Sebastian Andrzej Siewior
2010-11-30 20:31 ` Benjamin Herrenschmidt
2010-11-29 23:58 ` David Gibson
2010-11-29 19:36 ` [sodaville] " Sebastian Andrzej Siewior
2010-11-29 20:14 ` Benjamin Herrenschmidt
2010-11-29 2:22 ` David Gibson
2010-11-25 17:39 ` [PATCH 04/11] x86/dtb: add irq host abstraction Sebastian Andrzej Siewior
2010-11-25 19:30 ` Jon Loeliger
2010-11-26 14:19 ` Sebastian Andrzej Siewior
2010-11-26 21:36 ` Benjamin Herrenschmidt
2010-12-01 10:31 ` [sodaville] " Sebastian Andrzej Siewior
2010-11-27 3:11 ` Jon Loeliger
2010-11-25 17:39 ` [PATCH 05/11] x86/dtb: add early parsing of APIC and IO APIC Sebastian Andrzej Siewior
2010-11-25 17:39 ` [PATCH 06/11] x86/dtb: add support hpet Sebastian Andrzej Siewior
2010-11-25 17:39 ` [PATCH 07/11] x86/dtb: add support for PCI devices backed by dtb nodes Sebastian Andrzej Siewior
2010-11-27 22:33 ` Benjamin Herrenschmidt
2010-11-28 14:04 ` Sebastian Andrzej Siewior
2010-11-28 22:32 ` Benjamin Herrenschmidt
2010-12-02 16:17 ` Sebastian Andrzej Siewior
2010-11-25 17:39 ` [PATCH 08/11] x86/dtb: Add generic bus probe Sebastian Andrzej Siewior
2010-11-25 17:39 ` [PATCH 09/11] x86/ioapic: Add OF bindings for IO-APIC Sebastian Andrzej Siewior
2010-11-25 17:40 ` [PATCH 10/11] x86/io_apic: add simply id set Sebastian Andrzej Siewior
2010-11-25 21:04 ` Yinghai Lu
2010-11-26 11:03 ` Sebastian Andrzej Siewior
2010-11-26 16:50 ` [PATCH] x86/io_apic: split setup_ioapic_ids_from_mpc() into a non-checkign version Sebastian Andrzej Siewior
2010-12-06 13:33 ` [tip:x86/apic] x86: io_apic: Split setup_ioapic_ids_from_mpc() tip-bot for Sebastian Andrzej Siewior
2010-12-07 8:59 ` [PATCH -v2] x86, ioapic: Don't write io_apic ID if it is not changed Yinghai Lu
2010-12-09 20:56 ` [tip:x86/apic-cleanups] x86, ioapic: Avoid writing io_apic id if already correct tip-bot for Yinghai Lu
2010-11-25 17:40 ` [PATCH 11/11] x86/ce4100: use OF for ioapic Sebastian Andrzej Siewior
-- strict thread matches above, loose matches on Subject: below --
2011-02-22 20:07 Device tree on x86, part v4 Sebastian Andrzej Siewior
2011-02-22 20:07 ` [PATCH 03/11] x86/dtb: Add a device tree for CE4100 Sebastian Andrzej Siewior
2011-02-22 20:59 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CF41BDE.1030800@firmworks.com \
--to=wmb@firmworks.com \
--cc=benh@kernel.crashing.org \
--cc=bigeasy@linutronix.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scottwood@freescale.com \
--cc=sodaville@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox