From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Mitch Bradley <wmb@firmworks.com>,
linux-pci@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
Date: Thu, 14 Mar 2013 11:25:55 -0600 [thread overview]
Message-ID: <20130314172555.GA14048@obsidianresearch.com> (raw)
In-Reply-To: <20130314090120.GA2224@avionic-0098.mockup.avionic-design.de>
[trimm'd the cc list]
On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
> It turns out that this works with the Tegra driver because it uses the
> new of_pci_process_ranges() function and simply overwrites earlier
> matches by subsequent ones.
>
> ranges = <0x82000000 0 0 0x80000000 0 0x00001000 /* port 0 registers */
> 0x82000000 0 0 0x80001000 0 0x00001000 /* port 1 registers */
> 0x81000000 0 0 0x82000000 0 0x00010000 /* downstream I/O */
> 0x82000000 0 0 0xa0000000 0 0x10000000 /* non-prefetchable memory */
> 0xc2000000 0 0 0xb0000000 0 0x10000000>; /* prefetchable memory */
Okay.. There is still something funny here, the 3rd dword of the child
address should not be 0 in every line and there shouldn't be overlaps
in the child address space.
I'm assuming 0x80000000, 0xa0000000 and 0xb0000000 are real CPU physical
addresses?
Then it should probably look like:
ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000 /* port 0 registers */
0x82000000 0 0x80001000 0x80001000 0 0x00001000 /* port 1 registers */
0x81000000 0 0 0x82000000 0 0x00010000 /* downstream I/O */
0x82000000 0 0xa0000000 0xa0000000 0 0x10000000 /* non-prefetchable memory */
0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
Which says 'access to CPU address 0xa0000000 produces a PCI-E memory TLP with
address 0xa0000000' - this is the 'normal' case, I assume that is what
happens on tegra?
It also says 'access to CPU address 0x82000000 produces a PCI-E IO TLP
with address 0' - this translation is something Linux typically
expects..
Then you'd go on to have:
pci@1,0 {
device_type = "pci";
assigned-addresses = <0x82000000 0 0x80000000 0 0x1000>;
reg = <0x000800 0 0 0 0>;
}
pci@2,0 {
device_type = "pci";
assigned-addresses = <0x82000000 0 0x80001000 0 0x1000>;
reg = <0x001000 0 0 0 0>;
}
Notice I've made the upper dw of assigned-addresses's size 0 and
included the full 3dw from the appropriate ranges line.
> So the above will actually work along with the corresponding root-port
> "assigned-addresses" properties. I still don't like it much because I
> don't think it accurately reflects the hardware.
There are lots of valid ways to model the same HW :(
Bear in mind, for the PCI case - the OF PCI bindings model the HW
through the eyes of the abstractions in the PCI specification. That is
to say, they are not supposed to be an exact representation of the on
chip architecture.
Perhaps this would be clearer if you used 'pcie-root-complex' as the
name of the top level node?
> same kludgy, non-spec conformant smack that my original proposal had
> because it uses assigned-addresses for something it wasn't intended
> to.
Yes, only the top level 'reg' method avoids going outside any specs.
Regards,
Jason
next prev parent reply other threads:[~2013-03-14 17:25 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1360686546-24277-1-git-send-email-thomas.petazzoni@free-electrons.com>
[not found] ` <1360686546-24277-25-git-send-email-thomas.petazzoni@free-electrons.com>
[not found] ` <20130212223511.GB31555@obsidianresearch.com>
[not found] ` <20130306105441.4d24033e@skate>
[not found] ` <20130306121118.GA17079@avionic-0098.mockup.avionic-design.de>
[not found] ` <20130306180946.GA2433@obsidianresearch.com>
[not found] ` <20130307080832.GD3451@avionic-0098.mockup.avionic-design.de>
[not found] ` <20130307174955.GC20840@obsidianresearch.com>
[not found] ` <20130307194830.GA1811@avionic-0098.mockup.avionic-design.de>
[not found] ` <20130307200235.GB20695@obsidianresearch.com>
[not found] ` <20130307200235.GB20695-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-07 20:47 ` [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems Thierry Reding
2013-03-08 0:05 ` Rob Herring
2013-03-08 7:14 ` Thierry Reding
2013-03-08 16:52 ` Jason Gunthorpe
2013-03-08 19:12 ` Thierry Reding
[not found] ` <20130308191227.GA6551-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2013-03-08 19:43 ` Mitch Bradley
2013-03-08 20:02 ` Jason Gunthorpe
[not found] ` <20130308200245.GC29435-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-08 20:13 ` Thierry Reding
2013-03-10 15:09 ` Thomas Petazzoni
2013-03-11 8:08 ` Thierry Reding
2013-03-08 23:46 ` Mitch Bradley
2013-03-09 1:31 ` Jason Gunthorpe
[not found] ` <20130309013152.GA3883-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-10 4:52 ` Mitch Bradley
2013-03-10 6:55 ` Jason Gunthorpe
[not found] ` <20130310065539.GA14704-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-11 5:46 ` Mitch Bradley
[not found] ` <513D6F9C.9000100-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2013-03-11 7:46 ` Thierry Reding
[not found] ` <20130311074615.GA6365-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2013-03-11 18:04 ` Mitch Bradley
2013-03-11 18:23 ` Jason Gunthorpe
[not found] ` <20130311182339.GB10992-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-11 19:49 ` Mitch Bradley
2013-03-11 18:15 ` Jason Gunthorpe
[not found] ` <20130311181554.GA10992-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-11 21:50 ` Mitch Bradley
2013-03-11 23:25 ` Jason Gunthorpe
[not found] ` <20130311232516.GA13873-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-11 23:38 ` Mitch Bradley
[not found] ` <513E6AFE.3090304-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2013-03-12 7:08 ` Thierry Reding
2013-03-12 15:57 ` Jason Gunthorpe
2013-03-12 20:38 ` Thierry Reding
2013-03-12 21:03 ` Jason Gunthorpe
2013-03-12 21:30 ` Thierry Reding
2013-03-12 22:08 ` Jason Gunthorpe
2013-03-12 23:25 ` Mitch Bradley
2013-03-13 8:18 ` Thierry Reding
2013-03-13 17:02 ` Jason Gunthorpe
[not found] ` <20130313170205.GB24042-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-13 19:26 ` Thierry Reding
2013-03-13 19:59 ` Jason Gunthorpe
2013-03-13 20:54 ` Thierry Reding
2013-03-13 20:58 ` Mitch Bradley
2013-03-13 21:33 ` Thierry Reding
2013-03-13 22:48 ` Mitch Bradley
2013-03-14 0:43 ` Rob Herring
2013-03-14 1:20 ` Mitch Bradley
2013-03-14 7:11 ` Thierry Reding
2013-03-14 4:56 ` Stephen Warren
[not found] ` <5140E85A.3040900-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2013-03-13 22:02 ` Thierry Reding
2013-03-13 22:21 ` Jason Gunthorpe
2013-03-14 9:01 ` Thierry Reding
2013-03-14 17:25 ` Jason Gunthorpe [this message]
2013-03-14 20:38 ` Thierry Reding
2013-03-14 21:05 ` Jason Gunthorpe
2013-03-14 21:10 ` Mitch Bradley
2013-03-14 21:09 ` Thierry Reding
2013-03-14 21:29 ` Jason Gunthorpe
2013-03-14 21:37 ` Thierry Reding
2013-03-13 22:22 ` Jason Gunthorpe
2013-03-09 8:58 ` Thomas Petazzoni
2013-03-08 23:12 ` Rob Herring
[not found] ` <513A7044.1020700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-03-09 11:10 ` Thierry Reding
2013-03-10 5:04 ` Mitch Bradley
2013-03-10 15:06 ` Thomas Petazzoni
2013-03-10 18:33 ` Mitch Bradley
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=20130314172555.GA14048@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.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).