From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Mitch Bradley <wmb@firmworks.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>,
Lior Amsalem <alior@marvell.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
linux-pci@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
Eran Ben-Avi <benavi@marvell.com>,
Nadav Haklai <nadavh@marvell.com>,
Maen Suleiman <maen@marvell.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Shadi Ammouri <shadi@marvell.com>,
Tawfik Bayouk <tawfik@marvell.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
Date: Sat, 9 Mar 2013 23:55:39 -0700 [thread overview]
Message-ID: <20130310065539.GA14704@obsidianresearch.com> (raw)
In-Reply-To: <513C117D.6080800@firmworks.com>
On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
> Okay, I think I finally get it. The Marvell root port bridge setup
> registers look like standard config headers, even though they aren't
> really in config space (because you need a different access method for
> them, compared to real config accesses to downstream devices).
Well, thats pretty close. On Marvell the MMIO space has a lot of
stuff, some of it is config related, lots of it isn't. In fact most of
it isn't. Tegra is different, the MMIO region is exactly the config
space of the root port bridge.
Tegra could probably happily and sanely do as you've described (well,
see below), but it is wonky for Marvell. It looks like there are more
drivers coming that have this need - so I had hoped for a general
answer to the 'per-port MMIO space' problem that is unrelated to the
MMIO spaces role in config access.
> So, in order for the common code that enumerates the PCI bus to work,
> you need to "spoof" the config accesses so that when you try to access
> those particular "pseudo config headers", it uses the MMIO method
> instead of the real config access method.
There are rules for config access in both Tegra and Marvell that are
not trivial. Again, the driver takes are of this and all Linux sees is
a nice compliant config space.
> If that is indeed the case, them I would vote for a slight modification
> of the intermediate patch that I cited earlier - the one in which the
> ranges property includes translations from those special config
> addresses into CPU addresses. The modification is to fix the sizes,
> changing 0x2000 to 0x800, so those ranges entries do not overlap in the
> child address domain.
On Marvell the size of the MMIO space is 0x2000, there are imporant
registers there beyond index 0x800 (todays driver may not touch them
but HW has them). Reducing the size doesn't seem appropriate.
> pcie-controller {
> compatible = "marvell,armada-370-pcie";
> status = "disabled";
device_type = "pci";
Here as well, as you noted before?
> #address-cells = <3>;
> #size-cells = <2>;
>
> bus-range = <0x00 0xff>;
>
> ranges = <0x00000800 0 0 0xd4004000 0 0x00000800 /* Root
> port config header */
> 0x00001000 0 0 0xd4008000 0 0x00000800 /* Root
> port config header */
> 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000 /*
> non-prefetchable memory */
> 0x81000000 0 0 0xe8000000 0 0x00100000>; /*
> downstream I/O */
>
> pcie@1,0 {
> device_type = "pci";
> reg = <0x0800 0 0 0 0>;
Okay, this was Thierry's original idea, and it was my note that this
didn't seem like a good choice. I'm not wedded to that, but I'll
explain my reasoning a bit.
Two things bothered me
- Describing a CPU MMIO mapping with a config address space seems
wonky
- Linux's OF core doesn't parse a 'reg' property under
'device_type = "pci"' as something CPU mappable, it only looks
to assigned-addresses for that. So the OF core would need to learn
how to handle this case, and it would have to be well defined..
Thierry's original patch avoided this problem by not using
device_type = "pci"..
Also, did you mean to have a 0 size for the 'reg'? How will things
know how big the MMIO region is? Can't just assume 0x800..
Again, thanks!
Jason
next prev parent reply other threads:[~2013-03-10 6:55 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 [this message]
[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
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=20130310065539.GA14704@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=benavi@marvell.com \
--cc=bhelgaas@google.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=maen@marvell.com \
--cc=nadavh@marvell.com \
--cc=shadi@marvell.com \
--cc=tawfik@marvell.com \
--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).