linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs
Date: Mon, 10 Dec 2012 19:05:52 +0100	[thread overview]
Message-ID: <20121210190552.74acbe5a@skate> (raw)
In-Reply-To: <50C62161.9080708@wwwdotorg.org>

Dear Stephen Warren,

On Mon, 10 Dec 2012 10:52:33 -0700, Stephen Warren wrote:

> Mainly as background:
> 
> I /think/ Tegra has a similar HW setup (but perhaps not identical)
> (based on a very brief reading of your emails and brief knowledge of
> this aspect of the Tegra HW).
> 
> On Tegra, there is a 1GB physical address window that the PCIe
> controller serves. The controller has 2 or 3 ports, each a separate PCIe
> domain I believe. There are registers in the PCIe controller which route
> accessed made to the 1GB physical window to the various child ports and
> transaction types.

On Marvell SoCs, this is even more flexible: you have 20 configurable
address decoding windows. For each of them, you can configure the base
address, size, and target device (i.e PCIe port x.y, NAND, or some
other devices). And since we have up to 10 PCIe interfaces, we really
don't want to over-allocate hundreds of MB of physical address space for
each device, since most of them need only a few dozens of KB.

> IIRC, the bindings Thierry came up with for the Tegra PCIe controller
> statically describe the setup of those mappings (e.g. it could assign a
> 256MB physical address region to port 1, and a 768MB physical address
> region to port 2 perhaps?).
> 
> It sounds like Jason is advocating a much more dynamic approach on the
> Marvell HW. Perhaps this is related to whether the n host ports driven
> by the controller are separate PCIe domains (as I believe they are or
> can be on Tegra) or not.

The code I'm proposing for the Marvell PCIe is already dynamic it
doesn't describe the addresses in the DT, but instead dynamically
allocates address decoding windows according to the number of PCIe
devices that are found.

However, I haven't found yet how to get, during the ARM pcibios
initialization, the memory size needed for each device, so that I could
size the address decoding windows correctly instead of over-allocating
them (currently I allocate SZ_64MB for each window, even for my e1000e
PCIe card that needs only SZ_32K of PCI memory space).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2012-12-10 18:05 UTC|newest]

Thread overview: 107+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-07 22:04 [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT Thomas Petazzoni
2012-12-11 10:43   ` Arnd Bergmann
2012-12-11 16:03     ` Thomas Petazzoni
2012-12-11 16:15       ` Arnd Bergmann
2012-12-11 16:23         ` Russell King - ARM Linux
2012-12-11 16:38           ` Thomas Petazzoni
2012-12-11 16:50             ` Russell King - ARM Linux
2012-12-11 17:29             ` Alan Cox
2012-12-11 22:20               ` Arnd Bergmann
2012-12-11 22:34           ` Arnd Bergmann
2012-12-11 16:30         ` Thomas Petazzoni
2012-12-11 16:46           ` Russell King - ARM Linux
2012-12-11 17:32             ` Alan Cox
2012-12-11 22:28               ` Arnd Bergmann
2012-12-11 16:55           ` Russell King - ARM Linux
2012-12-11 16:26     ` Russell King - ARM Linux
2012-12-11 17:16       ` Alan Cox
2012-12-11 17:34         ` Russell King - ARM Linux
2012-12-11 17:45           ` Alan Cox
2012-12-11 17:51             ` Russell King - ARM Linux
2012-12-07 22:04 ` [RFC v1 02/16] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 03/16] arm: plat-orion: introduce WIN_CTRL_ENABLE in address mapping code Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 04/16] arm: plat-orion: refactor the orion_disable_wins() function Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc, free}_cpu_win() functions Thomas Petazzoni
2012-12-08 11:53   ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc,free}_cpu_win() functions Andrew Lunn
2012-12-08 12:15     ` Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 06/16] arm: mvebu: add functions to alloc/free PCIe decoding windows Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 07/16] arm: plat-orion: make common PCIe code usable on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 08/16] arm: mvebu: the core PCIe driver Thomas Petazzoni
2012-12-10  8:28   ` Andrew Lunn
2012-12-10  8:45     ` Thomas Petazzoni
2012-12-10 19:08   ` Jason Gunthorpe
2012-12-11 10:56   ` Arnd Bergmann
2012-12-12 15:58     ` Thomas Petazzoni
2012-12-12 21:51       ` Jason Gunthorpe
2012-12-13 14:58         ` Arnd Bergmann
2012-12-13 17:40           ` Jason Gunthorpe
2012-12-13 19:09             ` Thomas Petazzoni
2012-12-14 19:34         ` Rob Herring
2012-12-13 12:19       ` Arnd Bergmann
2012-12-13 17:54         ` Jason Gunthorpe
2012-12-13 19:12           ` Thomas Petazzoni
2012-12-13 21:46             ` Arnd Bergmann
2012-12-13 22:27               ` Jason Gunthorpe
2012-12-07 22:04 ` [RFC v1 09/16] arm: mvebu: PCIe support is now available on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 10/16] arm: mvebu: add PCIe Device Tree informations for Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 11/16] arm: mvebu: add PCIe Device Tree informations for Armada XP Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 12/16] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 13/16] arm: mvebu: PCIe Device Tree informations for Armada XP DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 14/16] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 15/16] arm: mvebu: PCIe Device Tree informations for Armada 370 DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 16/16] arm: mvebu: update defconfig with PCI and USB support Thomas Petazzoni
2012-12-07 23:33 ` [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Jason Gunthorpe
2012-12-10 17:52   ` Stephen Warren
2012-12-10 18:05     ` Thomas Petazzoni [this message]
2012-12-10 18:16       ` Stephen Warren
2012-12-10 18:59         ` Thomas Petazzoni
2012-12-10 19:07           ` Jason Gunthorpe
2012-12-10 20:08           ` Stephen Warren
2012-12-10 18:44     ` Jason Gunthorpe
2012-12-10 19:03       ` Thomas Petazzoni
2012-12-10 19:18         ` Jason Gunthorpe
2012-12-12 16:04           ` Thomas Petazzoni
2012-12-12 20:09             ` Jason Gunthorpe
2012-12-16 13:02               ` Thierry Reding
2012-12-11  7:52     ` Thierry Reding
2012-12-11 21:21       ` Stephen Warren
2012-12-12 20:34         ` Thierry Reding
2012-12-12 22:30           ` Stephen Warren
2012-12-13  7:03             ` Thierry Reding
2012-12-13  8:04               ` Jason Gunthorpe
2012-12-13  8:23                 ` Thierry Reding
2012-12-13 18:12                   ` Stephen Warren
2012-12-13 20:42                     ` Thierry Reding
2012-12-13 20:47                       ` Jason Gunthorpe
2012-12-13 21:16                         ` Thierry Reding
2012-12-14 10:05                         ` Thierry Reding
2012-12-14 15:10                       ` Thierry Reding
2012-12-14 17:27                         ` Jason Gunthorpe
2012-12-16 12:33                           ` Thierry Reding
2012-12-17 18:29                             ` Jason Gunthorpe
2012-12-17 19:41                               ` Thierry Reding
2012-12-18  2:10                                 ` Stephen Warren
2012-12-18  2:51                                   ` Jason Gunthorpe
2012-12-18 17:03                                     ` Stephen Warren
2012-12-20 15:32                                       ` Thierry Reding
2012-12-21 13:38                                         ` Jay Agarwal
2012-12-21 14:03                                           ` Thierry Reding
2012-12-22 14:50                                         ` Thomas Petazzoni
2012-12-28 21:06                                           ` Thierry Reding
2012-12-28 21:16                                             ` Thomas Petazzoni
2012-12-28 23:49                                               ` Stephen Warren
2012-12-29  8:09                                                 ` Thomas Petazzoni
2012-12-31 16:40                                                   ` Stephen Warren
2012-12-29  9:33                                                 ` Thierry Reding
2012-12-31 16:44                                                   ` Stephen Warren
2013-01-02 20:09                                                   ` Jason Gunthorpe
2013-01-03 14:20                                                     ` Thierry Reding
2012-12-28 23:51                                         ` Stephen Warren
2012-12-18  7:32                                   ` Thierry Reding
2013-01-03 14:39 ` Thierry Reding
2013-01-03 15:00   ` Bjorn Helgaas
2013-01-03 15:11     ` Thierry Reding
2013-01-03 15:09   ` Thomas Petazzoni
2013-01-03 15:56   ` Arnd Bergmann
2013-01-03 16:01     ` Thierry Reding

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=20121210190552.74acbe5a@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).