From: Bjorn Helgaas <bhelgaas@google.com>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
devicetree-discuss@lists.ozlabs.org,
Russell King <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org,
Colin Cross <ccross@android.com>, Olof Johansson <olof@lixom.net>,
Stephen Warren <swarren@wwwdotorg.org>,
Mitch Bradley <wmb@firmworks.com>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v3 10/10] ARM: tegra: pcie: Add device tree support
Date: Tue, 14 Aug 2012 16:50:26 -0700 [thread overview]
Message-ID: <CAErSpo6Awbx9-DWM3V02HUg7Xv4tWAhcLO7UKuT_0uXbpZ+nKw@mail.gmail.com> (raw)
In-Reply-To: <20120814201215.GA10542@avionic-0098.mockup.avionic-design.de>
On Tue, Aug 14, 2012 at 1:12 PM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> On Thu, Jul 26, 2012 at 09:55:12PM +0200, Thierry Reding wrote:
>> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
>> index a094c97..c886dff 100644
>> --- a/arch/arm/boot/dts/tegra20.dtsi
>> +++ b/arch/arm/boot/dts/tegra20.dtsi
>> @@ -199,6 +199,68 @@
>> #size-cells = <0>;
>> };
>>
>> + pcie-controller {
>> + compatible = "nvidia,tegra20-pcie";
>> + reg = <0x80003000 0x00000800 /* PADS registers */
>> + 0x80003800 0x00000200 /* AFI registers */
>> + 0x81000000 0x01000000 /* configuration space */
>> + 0x90000000 0x10000000>; /* extended configuration space */
>> + interrupts = <0 98 0x04 /* controller interrupt */
>> + 0 99 0x04>; /* MSI interrupt */
>> + status = "disabled";
>> +
>> + ranges = <0 0 0 0x80000000 0x00001000 /* root port 0 */
>> + 0 1 0 0x81000000 0x00800000 /* port 0 config space */
>> + 0 2 0 0x90000000 0x08000000 /* port 0 ext config space */
>> + 0 3 0 0x82000000 0x00010000 /* port 0 downstream I/O */
>> + 0 4 0 0xa0000000 0x08000000 /* port 0 non-prefetchable memory */
>> + 0 5 0 0xb0000000 0x08000000 /* port 0 prefetchable memory */
>> +
>> + 1 0 0 0x80001000 0x00001000 /* root port 1 */
>> + 1 1 0 0x81800000 0x00800000 /* port 1 config space */
>> + 1 2 0 0x98000000 0x08000000 /* port 1 ext config space */
>> + 1 3 0 0x82010000 0x00010000 /* port 1 downstream I/O */
>> + 1 4 0 0xa8000000 0x08000000 /* port 1 non-prefetchable memory */
>> + 1 5 0 0xb8000000 0x08000000>; /* port 1 prefetchable memory */
>
> I've been thinking about this some more. The translations for both the
> regular and extended configuration spaces are configured in the top-
> level PCIe controller. It is therefore wrong how they are passed to the
> PCI host bridges via the ranges property.
>
> I remember Mitch saying that it should be passed down to the children
> because it is partitioned among them, but since the layout is compatible
> with ECAM, the partitioning isn't as simple as what's in the tree. In
> fact the partitions will be dependent on the number of devices attached
> to the host bridges.
I don't understand this last bit about the number of devices attached
to the host bridges. Logically, the host bridge has a bus number
aperture that you can know up front, even before you know anything
about what devices are below it. On x86, for example, the ACPI _CRS
method has something like "[bus 00-7f]" in it, which means that any
buses in that range are below this bridge. That doesn't tell us
anything about which buses actually have devices on them, of course;
it's just analogous to the secondary and subordinate bus number
registers in a P2P bridge.
>> +
>> + #address-cells = <3>;
>> + #size-cells = <1>;
>> +
>> + pci@0 {
>> + device_type = "pciex";
>> + reg = <0 0 0 0x1000>;
>> + status = "disabled";
>> +
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> +
>> + ranges = <0x80000000 0 0 0 1 0 0 0x00800000 /* config space */
>> + 0x90000000 0 0 0 2 0 0 0x08000000 /* ext config space */
>> + 0x81000000 0 0 0 3 0 0 0x00010000 /* I/O */
>> + 0x82000000 0 0 0 4 0 0 0x08000000 /* non-prefetchable memory */
>> + 0xc2000000 0 0 0 5 0 0 0x08000000>; /* prefetchable memory */
>> +
>> + nvidia,num-lanes = <2>;
>> + };
>> +
>> + pci@1 {
>> + device_type = "pciex";
>> + reg = <1 0 0 0x1000>;
>> + status = "disabled";
>> +
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> +
>> + ranges = <0x80000000 0 0 1 1 0 0 0x00800000 /* config space */
>> + 0x90000000 0 0 1 2 0 0 0x08000000 /* ext config space */
>> + 0x81000000 0 0 1 3 0 0 0x00010000 /* I/O */
>> + 0x82000000 0 0 1 4 0 0 0x08000000 /* non-prefetchable memory */
>> + 0xc2000000 0 0 1 5 0 0 0x08000000>; /* prefetchable memory */
>> +
>> + nvidia,num-lanes = <2>;
>> + };
>> + };
>
> The same is true for the ranges properties of the PCI host bridge nodes.
> Which part of the configuration spaces maps to the children of the
> respective host bridge depends on the actual device hierarchy.
>
> Would it be possible to alternatively pass the complete range to the
> children without further partitioning?
>
> The driver doesn't actually care about the ranges property and only uses
> the values specified in the reg property of the pcie-controller node.
>
> Thierry
next prev parent reply other threads:[~2012-08-14 23:50 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 19:55 [PATCH v3 00/10] ARM: tegra: Add PCIe device tree support Thierry Reding
2012-07-26 19:55 ` [PATCH v3 01/10] PCI: Keep pci_fixup_irqs() around after init Thierry Reding
2012-08-14 5:06 ` Bjorn Helgaas
2012-08-14 5:37 ` Thierry Reding
2012-08-15 17:06 ` Bjorn Helgaas
2012-08-15 19:28 ` Thierry Reding
2012-08-15 19:42 ` Bjorn Helgaas
2012-08-15 20:01 ` Thierry Reding
2012-09-07 16:19 ` Stephen Warren
2012-09-07 17:00 ` Thierry Reding
2012-09-07 17:22 ` Bjorn Helgaas
2012-09-14 18:55 ` Thierry Reding
2012-09-14 19:45 ` Bjorn Helgaas
2012-07-26 19:55 ` [PATCH v3 02/10] ARM: pci: Keep pci_common_init() " Thierry Reding
2012-07-26 19:55 ` [PATCH v3 03/10] ARM: pci: Allow passing per-controller private data Thierry Reding
2012-07-26 19:55 ` [PATCH v3 04/10] ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC Thierry Reding
2012-07-26 19:55 ` [PATCH v3 05/10] resource: add PCI configuration space support Thierry Reding
2012-08-14 5:00 ` Bjorn Helgaas
2012-08-14 5:55 ` Thierry Reding
2012-08-14 17:38 ` Bjorn Helgaas
2012-08-14 18:01 ` Thierry Reding
2012-08-14 21:44 ` Bjorn Helgaas
2012-08-15 6:49 ` Thierry Reding
2012-08-16 15:18 ` Stephen Warren
2012-08-16 18:27 ` Thierry Reding
2012-07-26 19:55 ` [PATCH v3 06/10] ARM: tegra: Rewrite PCIe support as a driver Thierry Reding
2012-07-26 19:55 ` [PATCH v3 07/10] ARM: tegra: pcie: Add MSI support Thierry Reding
2012-07-26 19:55 ` [PATCH v3 08/10] of/address: Handle #address-cells > 2 specially Thierry Reding
2012-07-31 20:18 ` Rob Herring
2012-08-15 20:06 ` Thierry Reding
2012-09-07 16:24 ` Stephen Warren
2012-09-07 16:32 ` Rob Herring
2012-07-26 19:55 ` [PATCH v3 09/10] of: Add of_pci_parse_ranges() Thierry Reding
2012-07-31 20:07 ` Rob Herring
2012-08-01 6:54 ` Thierry Reding
2012-08-01 16:07 ` Stephen Warren
2012-07-26 19:55 ` [PATCH v3 10/10] ARM: tegra: pcie: Add device tree support Thierry Reding
2012-08-14 20:12 ` Thierry Reding
2012-08-14 23:50 ` Bjorn Helgaas [this message]
2012-08-15 6:37 ` Thierry Reding
2012-08-15 12:18 ` Bjorn Helgaas
2012-08-15 12:30 ` Thierry Reding
2012-08-15 14:36 ` Bjorn Helgaas
2012-08-15 14:57 ` Thierry Reding
2012-08-15 20:25 ` Arnd Bergmann
2012-08-15 20:48 ` Bjorn Helgaas
2012-08-16 4:55 ` Thierry Reding
2012-08-16 7:03 ` Arnd Bergmann
2012-08-16 7:47 ` Thierry Reding
2012-08-16 12:15 ` Thierry Reding
2012-07-31 16:18 ` [PATCH v3 00/10] ARM: tegra: Add PCIe " Stephen Warren
2012-08-01 6:35 ` Thierry Reding
2012-08-01 17:02 ` Stephen Warren
2012-08-02 6:15 ` Thierry Reding
2012-08-06 19:42 ` Stephen Warren
2012-08-07 18:20 ` Thierry Reding
2012-08-13 17:40 ` Thierry Reding
2012-08-13 18:47 ` Stephen Warren
2012-08-13 20:33 ` Thierry Reding
2012-08-13 21:38 ` Rob Herring
2012-08-14 6:14 ` Thierry Reding
2012-08-13 23:18 ` Bjorn Helgaas
2012-08-14 6:29 ` Thierry Reding
2012-08-14 19:39 ` Stephen Warren
2012-08-14 19:58 ` Thierry Reding
2012-08-14 21:55 ` Bjorn Helgaas
2012-08-14 22:58 ` Stephen Warren
2012-08-14 23:51 ` Stephen Warren
2012-08-15 19:04 ` Stephen Warren
2012-08-15 20:09 ` Thierry Reding
2012-08-15 20:11 ` Stephen Warren
2012-08-15 20:19 ` Thierry Reding
2012-09-07 23:34 ` Stephen Warren
2012-09-08 0:04 ` Russell King - ARM Linux
2012-09-08 5:53 ` Stephen Warren
2012-09-08 17:51 ` Bjorn Helgaas
2012-09-18 6:33 ` Thierry Reding
2012-09-18 15:56 ` Bjorn Helgaas
2012-08-15 0:08 ` Bjorn Helgaas
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=CAErSpo6Awbx9-DWM3V02HUg7Xv4tWAhcLO7UKuT_0uXbpZ+nKw@mail.gmail.com \
--to=bhelgaas@google.com \
--cc=arnd@arndb.de \
--cc=ccross@android.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=olof@lixom.net \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@avionic-design.de \
--cc=wmb@firmworks.com \
/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;
as well as URLs for NNTP newsgroup(s).