From: Stephen Warren <swarren@wwwdotorg.org> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>, Gregory Clement <gregory.clement@free-electrons.com>, Arnd Bergmann <arnd@arndb.de>, Maen Suleiman <maen@marvell.com>, Lior Amsalem <alior@marvell.com>, Thierry Reding <thierry.reding@avionic-design.de>, Eran Ben-Avi <benavi@marvell.com>, Nadav Haklai <nadavh@marvell.com>, Shadi Ammouri <shadi@marvell.com>, Tawfik Bayouk <tawfik@marvell.com>, Russell King - ARM Linux <linux@arm.linux.org.uk> Subject: Re: [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems Date: Thu, 31 Jan 2013 19:21:02 -0700 [thread overview] Message-ID: <510B268E.2040104@wwwdotorg.org> (raw) In-Reply-To: <20130201014138.GA16234@obsidianresearch.com> On 01/31/2013 06:41 PM, Jason Gunthorpe wrote: > On Thu, Jan 31, 2013 at 05:34:36PM -0700, Stephen Warren wrote: >> On 01/28/2013 11:56 AM, Thomas Petazzoni wrote: >>> This driver implements the support for the PCIe interfaces on the >>> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to >>> cover earlier families of Marvell SoCs, such as Dove, Orion and >>> Kirkwood. >> >> Bjorn and I happen to live very close, so we got together today and >> talked about PCIe on ARM. >> >> One of the questions he asked is: why does the window management on the >> Marvell SoCs need to be dynamic? > >> (Sorry if this was covered earlier; I vaguely recall some discussion on >> the topic, but couldn't find it quickly) > > Well I've answered it several times, so has Thomas.. Lets try again, > please save for future reference :) > > Lets seperate two things. > > The CPU physical address ranges reserved for PCI bus access are not > dynamic. This is set in DT, or whatever, statically. Just like every > other PCI case on ARM. Just like Tegra. That is not the issue. > > What is required is that the division of this space amongst the 10 > physical PCI-E links must be dynamic. Just like x86. Just like the new > tegra driver. [1] > > Is that clear? Yes. >> As background, PCIe enumeration in Linux usually works like: >> >> 1) You start off with some CPU physical address regions that generate >> transactions on the PCIe bus. >> >> 2) You enumerate all the PCIe devices, and assign an address to each BAR >> found, carved out of the PCIe address range corresponding to the regions >> you knew from (1). > > Step 2 also includes 'assign address windows to all the physical PCI-E > links'. This is very important because it is what this entire > discussion is about. OK. > Look at how tegra or x86 works, the CPU physical addresses for PCI-E > do nothing until the PCI-to-PCI bridge window registers in each link's > configuration space are setup. Until that is done the SOC doesn't know > which link to send the transaction to. >From my perspective, this is slightly the wrong way of describing the issue, but I see what you mean: At least on Tegra and I think x86, any transaction that goes to the physical PCIe aperture is translated onto (internal) PCIe bus 0, so the lack of window or PCIe/PCIe bridge BAR register programming doesn't prevent the transaction going /somewhere/ (even if "somewhere" is only half way to where it's useful!). The difference is pretty subtle. The issue is that without the PCIe/PCIe bridge BARs programmed, the PCIe transactions won't get off bus 0 and onto a downstream bus of one of the PCIe/PCIe bridges, or put another way, no PCIe/PCIe will claim the transaction that happens on PCIe bus 0 (Using "PCIe/PCIe bridge" above to mean "PCIe root port") > Marvell is the same, until the link's window registers are setup the > CPU addresses don't go anywhere. > > Notice this has absolutely no effect on the host bridge aperture. > This is a link-by-link configuration of what addresses *go down that > link*. Right. > The big difference is the link window registers for Marvell do not > conform to the PCI configuration space specification. They are Marvell > specific. > > This is what the glue code in the host driver does, it converts the > Marvell specificness into something the kernel can undertstand and > control. There are countless ways to do this, but please accept it > is necessary that it be done... Sure. >> Now, I recall that a related issue was that you are tight on CPU >> physical address space, and the second algorithm above would allow the >> size of the PCIe controller's window configuration to be as small as >> possible, and hence there would be more CPU physical address space >> available to fit in other peripherals. > > Physical address space is certainly a concern, but availability of > decoder windows is the major one. Each link requires one decoder > window for MMIO and one for IO, and possibly one for prefetch. The > chip doesn't have 30 decoder windows. So the allocation of decoders to > links must be dynamic, based on the requirements of the downstream > endports on the link. Oh I see... I originally thought the issue was that the windows were between CPU physical address space and the PCIe host controller itself. But in fact, the windows are between PCIe bus 0 and the root ports, so they're the equivalent of the standard PCIe root port (or PCIe/PCIe bridge) BAR registers. And related, these BAR/window registers are usually part of each PCIe root port itself, and hence there's a whole number dedicated to each root port, but on Marvell there's a *global* pool of these BARs/windows instead. Now I think I finally understand the architecture of your HW. >> However, why does this need to be dynamic? On a particular board, you >> know all the other (non-PCIe) peripherals that you need to fit into the >> CPU physical address space, so you know how much is left over for PCIe, >> so why not always make the PCIe window fill up all the available >> space, > > Because there is no such thing as an all-links PCIe window on this > hardware. > > Each link has a seperate window. > > If you get rid of all the dynamic allocation then every link must > statically reserve some portion of physical address space and some > number of decoder windows. > > That more or less means you need to know what is going to be on the > other side of every link when you write the DT. So, the dynamic programming of the windows on Marvell HW is the exact logical equivalent of programming a standard PCIe root port's BAR registers. It makes perfect sense that should be dynamic. Presumably this is something you can make work inside your emulated PCIe/PCIe bridge module, simply by capturing writes to the BAR registers, and translating them into writes to the Marvell window registers. Now, I do have one follow-on question: You said you don't have 30 windows, but how many do you have free after allocating windows to any other peripherals that need them, relative to (3 * number-of-root-ports-in-the-SoC)? (3 being IO+Mem+PrefetchableMem.) The thing here is that when the PCIe core writes to a root port BAR window to configure/enable it the first time, you'll need to capture that transaction and dynamically allocate a window and program it in a way equivalent to what the BAR register write would have achieved on standard HW. Later, the window might need resizing, or even to be completely disabled, if the PCIe core were to change the standard BAR register. Dynamically allocating a window when the BAR is written seems a little heavy-weight. So while it's obvious that window base address and size shouldn't be static, I wonder if the assignment of a specific window ID to a specific root port ID shouldn be dynamic or static. For example, if your HW configuration leaves you with 6 windows available, you could support 2 PCIe root ports by statically assigning 3 windows to serve each of those 2 root ports. Would that work, or are there systems where over-commit is needed, e.g. if there's no IO space behind a root port, you could get away with two windows per root port, and hence be able to run 3 root ports rather than just 2? Still, if you know which PCIe devices are being the root ports, you could still represent the over-commit statically in DT Still, I supose doing it dynamically in the driver does end up being a lot less to think about for someone creating the DT for a new board. Having to translate standard root port BAR register writes to Marvell window register allocation/writes would imply that the emulated root port code has to be very closely tied into the Marvell PCIe driver, and not something that could be at all generic in the most part. >> With a static window configuration in DT, you'd end up with a system >> that worked much like any x86 system or Tegra, with some static memory >> range available to PCIe. It's just that in your case, the region >> location/size could change from boot to boot based on DT, whereas it's >> hard-coded in HW for Tegra and I assume x86 too. > > How is this better? Now you have a system where you have to customize > the DT before you connect a PCI-E device. What if someone uses this > chip in a configuration with physical slots? How does that work? What > about hotplug? What about a unified kernel? That is *not* like x86 or > tegra. Right. Now that I really understand what the windows are doing, I can see that a static window configuration (address/size, perhaps rather than windows are used) would not be appropriate. > IMHO Thomas's direction in his proposed driver ends up working very > close to the new tegra driver, and has the sort of dynamic allocation > and discovery people expect from PCI-E. > > Jason > > 1 - The new tegra driver switches from calling ARM's pci_common_init > once for every physical link, to once for the SOC. It does this by > fixing the routing of config transactions so that the kernel sees > the per-link PCI-PCI root port bridge config space provided by the > hardware at the correct place. By doing this it changes from > statically allocating a physical memory region for each link to > statically allocating a region for all the links, and dynamically > dividing that region amongst the links. Right, we have both (or all 3) root ports show up in the same PCIe domain.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems Date: Thu, 31 Jan 2013 19:21:02 -0700 [thread overview] Message-ID: <510B268E.2040104@wwwdotorg.org> (raw) In-Reply-To: <20130201014138.GA16234@obsidianresearch.com> On 01/31/2013 06:41 PM, Jason Gunthorpe wrote: > On Thu, Jan 31, 2013 at 05:34:36PM -0700, Stephen Warren wrote: >> On 01/28/2013 11:56 AM, Thomas Petazzoni wrote: >>> This driver implements the support for the PCIe interfaces on the >>> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to >>> cover earlier families of Marvell SoCs, such as Dove, Orion and >>> Kirkwood. >> >> Bjorn and I happen to live very close, so we got together today and >> talked about PCIe on ARM. >> >> One of the questions he asked is: why does the window management on the >> Marvell SoCs need to be dynamic? > >> (Sorry if this was covered earlier; I vaguely recall some discussion on >> the topic, but couldn't find it quickly) > > Well I've answered it several times, so has Thomas.. Lets try again, > please save for future reference :) > > Lets seperate two things. > > The CPU physical address ranges reserved for PCI bus access are not > dynamic. This is set in DT, or whatever, statically. Just like every > other PCI case on ARM. Just like Tegra. That is not the issue. > > What is required is that the division of this space amongst the 10 > physical PCI-E links must be dynamic. Just like x86. Just like the new > tegra driver. [1] > > Is that clear? Yes. >> As background, PCIe enumeration in Linux usually works like: >> >> 1) You start off with some CPU physical address regions that generate >> transactions on the PCIe bus. >> >> 2) You enumerate all the PCIe devices, and assign an address to each BAR >> found, carved out of the PCIe address range corresponding to the regions >> you knew from (1). > > Step 2 also includes 'assign address windows to all the physical PCI-E > links'. This is very important because it is what this entire > discussion is about. OK. > Look at how tegra or x86 works, the CPU physical addresses for PCI-E > do nothing until the PCI-to-PCI bridge window registers in each link's > configuration space are setup. Until that is done the SOC doesn't know > which link to send the transaction to. >From my perspective, this is slightly the wrong way of describing the issue, but I see what you mean: At least on Tegra and I think x86, any transaction that goes to the physical PCIe aperture is translated onto (internal) PCIe bus 0, so the lack of window or PCIe/PCIe bridge BAR register programming doesn't prevent the transaction going /somewhere/ (even if "somewhere" is only half way to where it's useful!). The difference is pretty subtle. The issue is that without the PCIe/PCIe bridge BARs programmed, the PCIe transactions won't get off bus 0 and onto a downstream bus of one of the PCIe/PCIe bridges, or put another way, no PCIe/PCIe will claim the transaction that happens on PCIe bus 0 (Using "PCIe/PCIe bridge" above to mean "PCIe root port") > Marvell is the same, until the link's window registers are setup the > CPU addresses don't go anywhere. > > Notice this has absolutely no effect on the host bridge aperture. > This is a link-by-link configuration of what addresses *go down that > link*. Right. > The big difference is the link window registers for Marvell do not > conform to the PCI configuration space specification. They are Marvell > specific. > > This is what the glue code in the host driver does, it converts the > Marvell specificness into something the kernel can undertstand and > control. There are countless ways to do this, but please accept it > is necessary that it be done... Sure. >> Now, I recall that a related issue was that you are tight on CPU >> physical address space, and the second algorithm above would allow the >> size of the PCIe controller's window configuration to be as small as >> possible, and hence there would be more CPU physical address space >> available to fit in other peripherals. > > Physical address space is certainly a concern, but availability of > decoder windows is the major one. Each link requires one decoder > window for MMIO and one for IO, and possibly one for prefetch. The > chip doesn't have 30 decoder windows. So the allocation of decoders to > links must be dynamic, based on the requirements of the downstream > endports on the link. Oh I see... I originally thought the issue was that the windows were between CPU physical address space and the PCIe host controller itself. But in fact, the windows are between PCIe bus 0 and the root ports, so they're the equivalent of the standard PCIe root port (or PCIe/PCIe bridge) BAR registers. And related, these BAR/window registers are usually part of each PCIe root port itself, and hence there's a whole number dedicated to each root port, but on Marvell there's a *global* pool of these BARs/windows instead. Now I think I finally understand the architecture of your HW. >> However, why does this need to be dynamic? On a particular board, you >> know all the other (non-PCIe) peripherals that you need to fit into the >> CPU physical address space, so you know how much is left over for PCIe, >> so why not always make the PCIe window fill up all the available >> space, > > Because there is no such thing as an all-links PCIe window on this > hardware. > > Each link has a seperate window. > > If you get rid of all the dynamic allocation then every link must > statically reserve some portion of physical address space and some > number of decoder windows. > > That more or less means you need to know what is going to be on the > other side of every link when you write the DT. So, the dynamic programming of the windows on Marvell HW is the exact logical equivalent of programming a standard PCIe root port's BAR registers. It makes perfect sense that should be dynamic. Presumably this is something you can make work inside your emulated PCIe/PCIe bridge module, simply by capturing writes to the BAR registers, and translating them into writes to the Marvell window registers. Now, I do have one follow-on question: You said you don't have 30 windows, but how many do you have free after allocating windows to any other peripherals that need them, relative to (3 * number-of-root-ports-in-the-SoC)? (3 being IO+Mem+PrefetchableMem.) The thing here is that when the PCIe core writes to a root port BAR window to configure/enable it the first time, you'll need to capture that transaction and dynamically allocate a window and program it in a way equivalent to what the BAR register write would have achieved on standard HW. Later, the window might need resizing, or even to be completely disabled, if the PCIe core were to change the standard BAR register. Dynamically allocating a window when the BAR is written seems a little heavy-weight. So while it's obvious that window base address and size shouldn't be static, I wonder if the assignment of a specific window ID to a specific root port ID shouldn be dynamic or static. For example, if your HW configuration leaves you with 6 windows available, you could support 2 PCIe root ports by statically assigning 3 windows to serve each of those 2 root ports. Would that work, or are there systems where over-commit is needed, e.g. if there's no IO space behind a root port, you could get away with two windows per root port, and hence be able to run 3 root ports rather than just 2? Still, if you know which PCIe devices are being the root ports, you could still represent the over-commit statically in DT Still, I supose doing it dynamically in the driver does end up being a lot less to think about for someone creating the DT for a new board. Having to translate standard root port BAR register writes to Marvell window register allocation/writes would imply that the emulated root port code has to be very closely tied into the Marvell PCIe driver, and not something that could be at all generic in the most part. >> With a static window configuration in DT, you'd end up with a system >> that worked much like any x86 system or Tegra, with some static memory >> range available to PCIe. It's just that in your case, the region >> location/size could change from boot to boot based on DT, whereas it's >> hard-coded in HW for Tegra and I assume x86 too. > > How is this better? Now you have a system where you have to customize > the DT before you connect a PCI-E device. What if someone uses this > chip in a configuration with physical slots? How does that work? What > about hotplug? What about a unified kernel? That is *not* like x86 or > tegra. Right. Now that I really understand what the windows are doing, I can see that a static window configuration (address/size, perhaps rather than windows are used) would not be appropriate. > IMHO Thomas's direction in his proposed driver ends up working very > close to the new tegra driver, and has the sort of dynamic allocation > and discovery people expect from PCI-E. > > Jason > > 1 - The new tegra driver switches from calling ARM's pci_common_init > once for every physical link, to once for the SOC. It does this by > fixing the routing of config transactions so that the kernel sees > the per-link PCI-PCI root port bridge config space provided by the > hardware at the correct place. By doing this it changes from > statically allocating a physical memory region for each link to > statically allocating a region for all the links, and dynamically > dividing that region amongst the links. Right, we have both (or all 3) root ports show up in the same PCIe domain.
next prev parent reply other threads:[~2013-02-01 2:21 UTC|newest] Thread overview: 433+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-28 18:56 [PATCH v2] PCIe support for the Armada 370 and Armada XP SoCs Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 01/27] of/pci: Provide support for parsing PCI DT ranges property Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 02/27] of/pci: Add of_pci_get_devfn() function Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 22:00 ` Stephen Warren 2013-01-28 22:00 ` Stephen Warren 2013-01-28 22:16 ` Thierry Reding 2013-01-28 22:16 ` Thierry Reding 2013-01-29 10:04 ` Thomas Petazzoni 2013-01-29 10:04 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 03/27] of/pci: Add of_pci_parse_bus_range() function Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 04/27] ARM: pci: Allow passing per-controller private data Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 05/27] arm: pci: add a align_resource hook Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-29 15:12 ` Thomas Petazzoni 2013-01-29 15:12 ` Thomas Petazzoni 2013-01-29 15:15 ` Russell King - ARM Linux 2013-01-29 15:15 ` Russell King - ARM Linux 2013-01-29 15:23 ` Thomas Petazzoni 2013-01-29 15:23 ` Thomas Petazzoni 2013-01-29 15:25 ` Russell King - ARM Linux 2013-01-29 15:25 ` Russell King - ARM Linux 2013-01-29 15:28 ` Thomas Petazzoni 2013-01-29 15:28 ` Thomas Petazzoni 2013-01-29 15:58 ` Russell King - ARM Linux 2013-01-29 15:58 ` Russell King - ARM Linux 2013-01-29 16:20 ` Thomas Petazzoni 2013-01-29 16:20 ` Thomas Petazzoni 2013-01-29 16:45 ` Arnd Bergmann 2013-01-29 16:45 ` Arnd Bergmann 2013-01-29 17:09 ` Thomas Petazzoni 2013-01-29 17:09 ` Thomas Petazzoni 2013-01-29 20:15 ` Arnd Bergmann 2013-01-29 20:15 ` Arnd Bergmann 2013-01-29 20:33 ` Thomas Petazzoni 2013-01-29 20:33 ` Thomas Petazzoni 2013-01-29 21:59 ` Thomas Petazzoni 2013-01-29 21:59 ` Thomas Petazzoni 2013-01-29 22:17 ` Stephen Warren 2013-01-29 22:17 ` Stephen Warren 2013-01-30 4:49 ` Jason Gunthorpe 2013-01-30 4:49 ` Jason Gunthorpe 2013-01-29 22:54 ` Arnd Bergmann 2013-01-29 22:54 ` Arnd Bergmann 2013-01-30 4:21 ` Jason Gunthorpe 2013-01-30 4:21 ` Jason Gunthorpe 2013-01-30 9:55 ` Arnd Bergmann 2013-01-30 9:55 ` Arnd Bergmann 2013-01-30 11:47 ` Thomas Petazzoni 2013-01-30 11:47 ` Thomas Petazzoni 2013-01-30 16:17 ` Arnd Bergmann 2013-01-30 16:17 ` Arnd Bergmann 2013-01-30 16:38 ` Thomas Petazzoni 2013-01-30 16:38 ` Thomas Petazzoni 2013-01-30 20:48 ` Bjorn Helgaas 2013-01-30 20:48 ` Bjorn Helgaas 2013-01-30 21:06 ` Jason Gunthorpe 2013-01-30 21:06 ` Jason Gunthorpe 2013-01-30 4:56 ` Jason Gunthorpe 2013-01-30 4:56 ` Jason Gunthorpe 2013-01-30 8:19 ` Thomas Petazzoni 2013-01-30 8:19 ` Thomas Petazzoni 2013-01-30 9:46 ` Arnd Bergmann 2013-01-30 9:46 ` Arnd Bergmann 2013-01-30 9:54 ` Thomas Petazzoni 2013-01-30 9:54 ` Thomas Petazzoni 2013-01-30 10:03 ` Arnd Bergmann 2013-01-30 10:03 ` Arnd Bergmann 2013-01-30 11:42 ` Thomas Petazzoni 2013-01-30 11:42 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 06/27] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 07/27] PCI: Add software-emulated host bridge Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 20:18 ` Arnd Bergmann 2013-01-28 20:18 ` Arnd Bergmann 2013-01-28 22:03 ` Stephen Warren 2013-01-28 22:03 ` Stephen Warren 2013-01-28 22:09 ` Jason Gunthorpe 2013-01-28 22:09 ` Jason Gunthorpe 2013-01-28 22:18 ` Thomas Petazzoni 2013-01-28 22:18 ` Thomas Petazzoni 2013-01-28 22:23 ` Jason Gunthorpe 2013-01-28 22:23 ` Jason Gunthorpe 2013-01-28 22:30 ` Thomas Petazzoni 2013-01-28 22:30 ` Thomas Petazzoni 2013-01-28 22:51 ` Jason Gunthorpe 2013-01-28 22:51 ` Jason Gunthorpe 2013-01-29 10:01 ` Thomas Petazzoni 2013-01-29 10:01 ` Thomas Petazzoni 2013-01-29 17:42 ` Jason Gunthorpe 2013-01-29 17:42 ` Jason Gunthorpe 2013-01-29 17:43 ` Thomas Petazzoni 2013-01-29 17:43 ` Thomas Petazzoni 2013-01-29 2:40 ` Bjorn Helgaas 2013-01-29 2:40 ` Bjorn Helgaas 2013-01-29 6:16 ` Jason Gunthorpe 2013-01-29 6:16 ` Jason Gunthorpe 2013-01-28 22:09 ` Thomas Petazzoni 2013-01-28 22:09 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 08/27] pci: implement an emulated PCI-to-PCI bridge Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 19:35 ` Jason Gunthorpe 2013-01-28 19:35 ` Jason Gunthorpe 2013-01-28 19:39 ` Thomas Petazzoni 2013-01-28 19:39 ` Thomas Petazzoni 2013-01-28 19:55 ` Jason Gunthorpe 2013-01-28 19:55 ` Jason Gunthorpe 2013-01-28 22:06 ` Stephen Warren 2013-01-28 22:06 ` Stephen Warren 2013-01-28 22:16 ` Jason Gunthorpe 2013-01-28 22:16 ` Jason Gunthorpe 2013-01-29 22:35 ` Bjorn Helgaas 2013-01-29 22:35 ` Bjorn Helgaas 2013-01-29 23:06 ` Arnd Bergmann 2013-01-29 23:06 ` Arnd Bergmann 2013-01-30 4:12 ` Jason Gunthorpe 2013-01-30 4:12 ` Jason Gunthorpe 2013-01-28 18:56 ` [PATCH v2 09/27] pci: infrastructure to add drivers in drivers/pci/host Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 10/27] arm: mvebu: fix address-cells in mpic DT node Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 11/27] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 22:08 ` Stephen Warren 2013-01-28 22:08 ` Stephen Warren 2013-01-28 22:21 ` Thomas Petazzoni 2013-01-28 22:21 ` Thomas Petazzoni 2013-01-28 22:27 ` Stephen Warren 2013-01-28 22:27 ` Stephen Warren 2013-01-28 22:44 ` Thomas Petazzoni 2013-01-28 22:44 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 12/27] clk: mvebu: add more PCIe clocks for Armada XP Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 13/27] arm: plat-orion: introduce WIN_CTRL_ENABLE in address mapping code Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 14/27] arm: plat-orion: refactor the orion_disable_wins() function Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 15/27] arm: plat-orion: introduce orion_{alloc,free}_cpu_win() functions Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 15/27] arm: plat-orion: introduce orion_{alloc, free}_cpu_win() functions Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 16/27] arm: mvebu: add functions to alloc/free PCIe decoding windows Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 17/27] arm: plat-orion: make common PCIe code usable on mvebu Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 18/27] arm: plat-orion: add more flexible PCI configuration space read/write functions Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 19:51 ` Jason Gunthorpe 2013-01-28 19:51 ` Jason Gunthorpe 2013-01-29 8:40 ` Thomas Petazzoni 2013-01-29 8:40 ` Thomas Petazzoni 2013-01-29 17:40 ` Jason Gunthorpe 2013-01-29 17:40 ` Jason Gunthorpe 2013-01-28 18:56 ` [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 22:21 ` Stephen Warren 2013-01-28 22:21 ` Stephen Warren 2013-01-29 8:41 ` Thomas Petazzoni 2013-01-29 8:41 ` Thomas Petazzoni 2013-01-29 9:20 ` Thierry Reding 2013-01-29 9:20 ` Thierry Reding 2013-01-29 9:21 ` Thomas Petazzoni 2013-01-29 9:21 ` Thomas Petazzoni 2013-02-07 10:24 ` Thomas Petazzoni 2013-02-07 10:24 ` Thomas Petazzoni 2013-02-07 15:46 ` Bjorn Helgaas 2013-02-07 15:46 ` Bjorn Helgaas 2013-02-07 16:00 ` Thomas Petazzoni 2013-02-07 16:00 ` Thomas Petazzoni 2013-02-07 18:08 ` Bjorn Helgaas 2013-02-07 18:08 ` Bjorn Helgaas 2013-02-07 18:15 ` Jason Gunthorpe 2013-02-07 18:15 ` Jason Gunthorpe 2013-02-07 18:30 ` Bjorn Helgaas 2013-02-07 18:30 ` Bjorn Helgaas 2013-02-07 18:43 ` Thierry Reding 2013-02-07 18:43 ` Thierry Reding 2013-01-29 19:47 ` Stephen Warren 2013-01-29 19:47 ` Stephen Warren 2013-01-29 3:29 ` Bjorn Helgaas 2013-01-29 3:29 ` Bjorn Helgaas 2013-01-29 5:55 ` Jason Gunthorpe 2013-01-29 5:55 ` Jason Gunthorpe 2013-01-29 8:00 ` Thomas Petazzoni 2013-01-29 8:00 ` Thomas Petazzoni 2013-01-29 17:47 ` Bjorn Helgaas 2013-01-29 17:47 ` Bjorn Helgaas 2013-01-29 18:14 ` Thomas Petazzoni 2013-01-29 18:14 ` Thomas Petazzoni 2013-01-29 18:41 ` Jason Gunthorpe 2013-01-29 18:41 ` Jason Gunthorpe 2013-01-29 19:07 ` Bjorn Helgaas 2013-01-29 19:07 ` Bjorn Helgaas 2013-01-29 19:18 ` Jason Gunthorpe 2013-01-29 19:18 ` Jason Gunthorpe 2013-01-29 19:38 ` Bjorn Helgaas 2013-01-29 19:38 ` Bjorn Helgaas 2013-01-29 22:27 ` Bjorn Helgaas 2013-01-29 22:27 ` Bjorn Helgaas 2013-01-30 4:24 ` Jason Gunthorpe 2013-01-30 4:24 ` Jason Gunthorpe 2013-01-30 9:35 ` Thomas Petazzoni 2013-01-30 9:35 ` Thomas Petazzoni 2013-01-30 18:52 ` Bjorn Helgaas 2013-01-30 18:52 ` Bjorn Helgaas 2013-01-30 22:28 ` Thomas Petazzoni 2013-01-30 22:28 ` Thomas Petazzoni 2013-01-30 23:10 ` Jason Gunthorpe 2013-01-30 23:10 ` Jason Gunthorpe 2013-01-30 23:48 ` Bjorn Helgaas 2013-01-30 23:48 ` Bjorn Helgaas 2013-01-31 16:04 ` Thomas Petazzoni 2013-01-31 16:04 ` Thomas Petazzoni 2013-01-31 16:30 ` Bjorn Helgaas 2013-01-31 16:30 ` Bjorn Helgaas 2013-01-31 16:33 ` Thomas Petazzoni 2013-01-31 16:33 ` Thomas Petazzoni 2013-01-31 17:03 ` Bjorn Helgaas 2013-01-31 17:03 ` Bjorn Helgaas 2013-01-31 16:42 ` Russell King - ARM Linux 2013-01-31 16:42 ` Russell King - ARM Linux 2013-01-29 13:22 ` Andrew Murray 2013-01-29 13:22 ` Andrew Murray 2013-01-29 13:45 ` Thomas Petazzoni 2013-01-29 13:45 ` Thomas Petazzoni 2013-01-29 14:05 ` Andrew Murray 2013-01-29 14:05 ` Andrew Murray 2013-01-29 14:20 ` Thierry Reding 2013-01-29 14:20 ` Thierry Reding 2013-01-29 14:29 ` Thomas Petazzoni 2013-01-29 14:29 ` Thomas Petazzoni 2013-01-29 15:02 ` Thierry Reding 2013-01-29 15:02 ` Thierry Reding 2013-01-29 15:08 ` Andrew Murray 2013-01-29 15:08 ` Andrew Murray 2013-01-29 15:10 ` Thomas Petazzoni 2013-01-29 15:10 ` Thomas Petazzoni 2013-02-07 14:37 ` Thomas Petazzoni 2013-02-07 14:37 ` Thomas Petazzoni 2013-02-07 15:51 ` Andrew Murray 2013-02-07 15:51 ` Andrew Murray 2013-02-07 16:19 ` Thomas Petazzoni 2013-02-07 16:19 ` Thomas Petazzoni 2013-02-07 16:40 ` Thomas Petazzoni 2013-02-07 16:40 ` Thomas Petazzoni 2013-02-07 16:53 ` Andrew Murray 2013-02-07 16:53 ` Andrew Murray 2013-02-07 17:14 ` Thomas Petazzoni 2013-02-07 17:14 ` Thomas Petazzoni 2013-02-07 17:29 ` Andrew Murray 2013-02-07 17:29 ` Andrew Murray 2013-02-07 17:37 ` Thomas Petazzoni 2013-02-07 17:37 ` Thomas Petazzoni 2013-02-07 18:21 ` Jason Gunthorpe 2013-02-07 18:21 ` Jason Gunthorpe 2013-02-07 23:25 ` Arnd Bergmann 2013-02-07 23:25 ` Arnd Bergmann 2013-02-08 0:44 ` Jason Gunthorpe 2013-02-08 0:44 ` Jason Gunthorpe 2013-02-09 22:23 ` Arnd Bergmann 2013-02-09 22:23 ` Arnd Bergmann 2013-02-12 19:26 ` Jason Gunthorpe 2013-02-12 19:26 ` Jason Gunthorpe 2013-02-07 18:30 ` Andrew Murray 2013-02-07 18:30 ` Andrew Murray 2013-02-07 23:27 ` Arnd Bergmann 2013-02-07 23:27 ` Arnd Bergmann 2013-01-30 11:32 ` Russell King - ARM Linux 2013-01-30 11:32 ` Russell King - ARM Linux 2013-01-30 11:37 ` Thomas Petazzoni 2013-01-30 11:37 ` Thomas Petazzoni 2013-01-30 12:03 ` Thierry Reding 2013-01-30 12:03 ` Thierry Reding 2013-01-30 13:07 ` Thomas Petazzoni 2013-01-30 13:07 ` Thomas Petazzoni 2013-01-30 15:08 ` Russell King - ARM Linux 2013-01-30 15:08 ` Russell King - ARM Linux 2013-01-30 15:19 ` Russell King - ARM Linux 2013-01-30 15:19 ` Russell King - ARM Linux 2013-01-30 15:36 ` Thomas Petazzoni 2013-01-30 15:36 ` Thomas Petazzoni 2013-01-30 15:46 ` Russell King - ARM Linux 2013-01-30 15:46 ` Russell King - ARM Linux 2013-01-31 14:30 ` Thomas Petazzoni 2013-01-31 14:30 ` Thomas Petazzoni 2013-01-31 14:50 ` Russell King - ARM Linux 2013-01-31 14:50 ` Russell King - ARM Linux 2013-01-31 14:57 ` Thomas Petazzoni 2013-01-31 14:57 ` Thomas Petazzoni 2013-01-31 15:08 ` Russell King - ARM Linux 2013-01-31 15:08 ` Russell King - ARM Linux 2013-01-31 15:22 ` Thomas Petazzoni 2013-01-31 15:22 ` Thomas Petazzoni 2013-01-31 15:36 ` Russell King - ARM Linux 2013-01-31 15:36 ` Russell King - ARM Linux 2013-01-31 15:47 ` Thomas Petazzoni 2013-01-31 15:47 ` Thomas Petazzoni 2013-01-31 15:48 ` Russell King - ARM Linux 2013-01-31 15:48 ` Russell King - ARM Linux 2013-01-31 16:18 ` Arnd Bergmann 2013-01-31 16:18 ` Arnd Bergmann 2013-01-31 18:02 ` Jason Gunthorpe 2013-01-31 18:02 ` Jason Gunthorpe 2013-01-31 20:46 ` Arnd Bergmann 2013-01-31 20:46 ` Arnd Bergmann 2013-01-31 22:44 ` Jason Gunthorpe 2013-01-31 22:44 ` Jason Gunthorpe 2013-02-01 11:30 ` Arnd Bergmann 2013-02-01 11:30 ` Arnd Bergmann 2013-02-01 19:52 ` Jason Gunthorpe 2013-02-01 19:52 ` Jason Gunthorpe 2013-02-06 16:51 ` Thomas Petazzoni 2013-02-06 16:51 ` Thomas Petazzoni 2013-02-06 17:09 ` Jason Gunthorpe 2013-02-06 17:09 ` Jason Gunthorpe 2013-02-06 17:18 ` Thomas Petazzoni 2013-02-06 17:18 ` Thomas Petazzoni 2013-02-06 17:50 ` Jason Gunthorpe 2013-02-06 17:50 ` Jason Gunthorpe 2013-02-06 18:02 ` Thomas Petazzoni 2013-02-06 18:02 ` Thomas Petazzoni 2013-02-06 18:22 ` Stephen Warren 2013-02-06 18:22 ` Stephen Warren 2013-02-06 18:39 ` Jason Gunthorpe 2013-02-06 18:39 ` Jason Gunthorpe 2013-02-06 18:42 ` Thomas Petazzoni 2013-02-06 18:42 ` Thomas Petazzoni 2013-02-06 22:04 ` Arnd Bergmann 2013-02-06 22:04 ` Arnd Bergmann 2013-02-07 15:50 ` Giving special alignment/size constraints to the Linux PCI core? Thomas Petazzoni 2013-02-07 23:33 ` Arnd Bergmann 2013-02-07 23:33 ` Arnd Bergmann 2013-02-08 4:21 ` Bjorn Helgaas 2013-02-08 4:21 ` Bjorn Helgaas 2013-02-08 8:14 ` Thomas Petazzoni 2013-02-08 8:14 ` Thomas Petazzoni 2013-02-12 16:00 ` Arnd Bergmann 2013-02-12 16:00 ` Arnd Bergmann 2013-02-12 18:41 ` Jason Gunthorpe 2013-02-12 18:41 ` Jason Gunthorpe 2013-02-12 19:02 ` Arnd Bergmann 2013-02-12 19:02 ` Arnd Bergmann 2013-02-12 19:38 ` Jason Gunthorpe 2013-02-12 19:38 ` Jason Gunthorpe 2013-02-12 23:05 ` Arnd Bergmann 2013-02-12 23:05 ` Arnd Bergmann 2013-02-13 0:32 ` Jason Gunthorpe 2013-02-13 0:32 ` Jason Gunthorpe 2013-02-13 18:53 ` Arnd Bergmann 2013-02-13 18:53 ` Arnd Bergmann 2013-02-13 19:12 ` Jason Gunthorpe 2013-02-13 19:12 ` Jason Gunthorpe 2013-02-13 19:51 ` Thomas Petazzoni 2013-02-13 19:51 ` Thomas Petazzoni 2013-02-13 21:10 ` Arnd Bergmann 2013-02-13 21:10 ` Arnd Bergmann 2013-02-13 21:20 ` Yinghai Lu 2013-02-13 21:20 ` Yinghai Lu 2013-02-13 22:24 ` Arnd Bergmann 2013-02-13 22:24 ` Arnd Bergmann 2013-02-13 21:02 ` Yinghai Lu 2013-02-13 21:02 ` Yinghai Lu 2013-01-31 7:10 ` [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems Thierry Reding 2013-01-31 7:10 ` Thierry Reding 2013-02-01 0:34 ` Stephen Warren 2013-02-01 0:34 ` Stephen Warren 2013-02-01 1:41 ` Jason Gunthorpe 2013-02-01 1:41 ` Jason Gunthorpe 2013-02-01 2:21 ` Stephen Warren [this message] 2013-02-01 2:21 ` Stephen Warren 2013-02-01 3:51 ` Jason Gunthorpe 2013-02-01 3:51 ` Jason Gunthorpe 2013-02-01 9:03 ` Thomas Petazzoni 2013-02-01 9:03 ` Thomas Petazzoni 2013-02-01 16:07 ` Arnd Bergmann 2013-02-01 16:07 ` Arnd Bergmann 2013-02-01 16:26 ` Russell King - ARM Linux 2013-02-01 16:26 ` Russell King - ARM Linux 2013-02-01 17:45 ` Arnd Bergmann 2013-02-01 17:45 ` Arnd Bergmann 2013-02-01 19:58 ` Jason Gunthorpe 2013-02-01 19:58 ` Jason Gunthorpe 2013-02-01 8:46 ` Thomas Petazzoni 2013-02-01 8:46 ` Thomas Petazzoni 2013-02-01 16:02 ` Arnd Bergmann 2013-02-01 16:02 ` Arnd Bergmann 2013-02-01 17:57 ` Stephen Warren 2013-02-01 17:57 ` Stephen Warren 2013-02-01 19:39 ` Jason Gunthorpe 2013-02-01 19:39 ` Jason Gunthorpe 2013-02-01 20:30 ` Stephen Warren 2013-02-01 20:30 ` Stephen Warren 2013-01-28 18:56 ` [PATCH v2 20/27] arm: mvebu: PCIe support is now available on mvebu Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 21/27] arm: mvebu: add PCIe Device Tree informations for Armada 370 Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 22/27] arm: mvebu: add PCIe Device Tree informations for Armada XP Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-02-06 22:41 ` Arnd Bergmann 2013-02-06 22:41 ` Arnd Bergmann 2013-02-06 23:07 ` Thomas Petazzoni 2013-02-06 23:07 ` Thomas Petazzoni 2013-02-07 8:04 ` Arnd Bergmann 2013-02-07 8:04 ` Arnd Bergmann 2013-02-07 8:45 ` Thomas Petazzoni 2013-02-07 8:45 ` Thomas Petazzoni 2013-02-07 9:09 ` Arnd Bergmann 2013-02-07 9:09 ` Arnd Bergmann 2013-02-07 1:05 ` Jason Gunthorpe 2013-02-07 1:05 ` Jason Gunthorpe 2013-02-07 7:28 ` Thierry Reding 2013-02-07 7:28 ` Thierry Reding 2013-02-07 17:49 ` Jason Gunthorpe 2013-02-07 17:49 ` Jason Gunthorpe 2013-02-07 8:24 ` Arnd Bergmann 2013-02-07 8:24 ` Arnd Bergmann 2013-02-07 17:00 ` Jason Gunthorpe 2013-02-07 17:00 ` Jason Gunthorpe 2013-02-07 23:44 ` Arnd Bergmann 2013-02-07 23:44 ` Arnd Bergmann 2013-01-28 18:56 ` [PATCH v2 23/27] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 24/27] arm: mvebu: PCIe Device Tree informations for Armada XP DB Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 25/27] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 26/27] arm: mvebu: PCIe Device Tree informations for Armada 370 DB Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni 2013-01-28 18:56 ` [PATCH v2 27/27] arm: mvebu: update defconfig with PCI and USB support Thomas Petazzoni 2013-01-28 18:56 ` Thomas Petazzoni
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=510B268E.2040104@wwwdotorg.org \ --to=swarren@wwwdotorg.org \ --cc=alior@marvell.com \ --cc=andrew@lunn.ch \ --cc=arnd@arndb.de \ --cc=benavi@marvell.com \ --cc=bhelgaas@google.com \ --cc=gregory.clement@free-electrons.com \ --cc=jason@lakedaemon.net \ --cc=jgunthorpe@obsidianresearch.com \ --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=thomas.petazzoni@free-electrons.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.