From: Thierry Reding <thierry.reding@avionic-design.de> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> 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 21:38:58 +0100 [thread overview] Message-ID: <20130314203858.GA4539@avionic-0098.mockup.avionic-design.de> (raw) In-Reply-To: <20130314172555.GA14048@obsidianresearch.com> [-- Attachment #1: Type: text/plain, Size: 3852 bytes --] On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote: > [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? Yes. > 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. Okay, that all makes sense. > > 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. That seems to be at odds with most other uses of DT that I've come across. Generally the guideline seems to be to describe hardware irrespective of the underlying implementation and leave it up to the driver to translate the DT description into something the OS can use. > Perhaps this would be clearer if you used 'pcie-root-complex' as the > name of the top level node? Perhaps. I'm not sure. > > 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. Yes. It has a couple of other disadvantages, though, so if what we've been discussing here is in any way acceptable I'd rather go with that solution, even if I'm not entirely happy about it either. Thierry [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@avionic-design.de (Thierry Reding) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems Date: Thu, 14 Mar 2013 21:38:58 +0100 [thread overview] Message-ID: <20130314203858.GA4539@avionic-0098.mockup.avionic-design.de> (raw) In-Reply-To: <20130314172555.GA14048@obsidianresearch.com> On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote: > [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? Yes. > 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 at 1,0 { > device_type = "pci"; > assigned-addresses = <0x82000000 0 0x80000000 0 0x1000>; > reg = <0x000800 0 0 0 0>; > } > pci at 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. Okay, that all makes sense. > > 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. That seems to be at odds with most other uses of DT that I've come across. Generally the guideline seems to be to describe hardware irrespective of the underlying implementation and leave it up to the driver to translate the DT description into something the OS can use. > Perhaps this would be clearer if you used 'pcie-root-complex' as the > name of the top level node? Perhaps. I'm not sure. > > 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. Yes. It has a couple of other disadvantages, though, so if what we've been discussing here is in any way acceptable I'd rather go with that solution, even if I'm not entirely happy about it either. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130314/b7e57fbb/attachment-0001.sig>
next prev parent reply other threads:[~2013-03-14 20:38 UTC|newest] Thread overview: 291+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-12 16:28 [PATCH v3] PCIe support for the Armada 370 and Armada XP SoCs Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 01/32] of/pci: Provide support for parsing PCI DT ranges property Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 02/32] of/pci: Add of_pci_get_devfn() function Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 03/32] of/pci: Add of_pci_parse_bus_range() function Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 04/32] ARM: pci: Allow passing per-controller private data Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 05/32] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 18:00 ` Arnd Bergmann 2013-02-12 18:00 ` Arnd Bergmann 2013-02-12 18:58 ` Thomas Petazzoni 2013-02-12 18:58 ` Thomas Petazzoni 2013-02-12 22:36 ` Arnd Bergmann 2013-02-12 22:36 ` Arnd Bergmann 2013-03-04 16:28 ` Thomas Petazzoni 2013-03-04 16:28 ` Thomas Petazzoni 2013-03-04 20:30 ` Arnd Bergmann 2013-03-04 20:30 ` Arnd Bergmann 2013-02-12 16:28 ` [PATCH 06/32] arm: pci: add a align_resource hook Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 18:03 ` Arnd Bergmann 2013-02-12 18:03 ` Arnd Bergmann 2013-02-12 19:01 ` Thomas Petazzoni 2013-02-12 19:01 ` Thomas Petazzoni 2013-02-12 19:49 ` Russell King - ARM Linux 2013-02-12 19:49 ` Russell King - ARM Linux 2013-02-12 16:28 ` [PATCH 07/32] arm: mvebu: fix address-cells in mpic DT node Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 08/32] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 09/32] clk: mvebu: add more PCIe clocks for Armada XP Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 10/32] arm: plat-orion: introduce WIN_CTRL_ENABLE in address mapping code Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 11/32] arm: plat-orion: refactor the orion_disable_wins() function Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 12/32] plat-orion: introduce ORION_ADDR_MAP_NO_REMAP Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 13/32] arm: mach-dove: use ORION_ADDR_MAP_NO_REMAP Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 14/32] arm: mach-kirkwood: " Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 15/32] arm: mach-mvebu: " Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 16/32] arm: mach-orion5x: " Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 17/32] arm: plat-orion: convert 'int remap' to 'u32 remap' Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 18/32] arm: plat-orion: remove __init from addr-map functions needed after boot time Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 19/32] arm: plat-orion: introduce orion_{alloc,free}_cpu_win() functions Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 19/32] arm: plat-orion: introduce orion_{alloc, free}_cpu_win() functions Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 20/32] arm: plat-orion: remove __init from PCIe functions needed after boot time Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 21/32] arm: mvebu: add functions to alloc/free PCIe decoding windows Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 22/32] arm: plat-orion: make common PCIe code usable on mvebu Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 23/32] pci: infrastructure to add drivers in drivers/pci/host Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:28 ` [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 18:30 ` Arnd Bergmann 2013-02-12 18:30 ` Arnd Bergmann 2013-02-12 19:22 ` Thomas Petazzoni 2013-02-12 19:22 ` Thomas Petazzoni 2013-02-12 19:49 ` Jason Gunthorpe 2013-02-12 19:49 ` Jason Gunthorpe 2013-02-12 22:59 ` Arnd Bergmann 2013-02-12 22:59 ` Arnd Bergmann 2013-02-13 0:41 ` Jason Gunthorpe 2013-02-13 0:41 ` Jason Gunthorpe 2013-02-13 9:18 ` Arnd Bergmann 2013-02-13 9:18 ` Arnd Bergmann 2013-02-13 9:31 ` Thomas Petazzoni 2013-02-13 9:31 ` Thomas Petazzoni 2013-02-13 10:23 ` Arnd Bergmann 2013-02-13 10:23 ` Arnd Bergmann 2013-02-13 8:23 ` Thomas Petazzoni 2013-02-13 8:23 ` Thomas Petazzoni 2013-02-13 9:29 ` Arnd Bergmann 2013-02-13 9:29 ` Arnd Bergmann 2013-02-13 9:40 ` Thomas Petazzoni 2013-02-13 9:40 ` Thomas Petazzoni 2013-02-13 10:37 ` Arnd Bergmann 2013-02-13 10:37 ` Arnd Bergmann 2013-03-06 9:50 ` Thomas Petazzoni 2013-03-06 9:50 ` Thomas Petazzoni 2013-03-06 10:43 ` Arnd Bergmann 2013-03-06 10:43 ` Arnd Bergmann 2013-02-12 22:35 ` Jason Gunthorpe 2013-02-12 22:35 ` Jason Gunthorpe 2013-02-13 8:57 ` Thomas Petazzoni 2013-02-13 8:57 ` Thomas Petazzoni 2013-02-13 18:04 ` Jason Gunthorpe 2013-02-13 18:04 ` Jason Gunthorpe 2013-02-13 19:33 ` Arnd Bergmann 2013-02-13 19:33 ` Arnd Bergmann 2013-03-06 9:54 ` Thomas Petazzoni 2013-03-06 9:54 ` Thomas Petazzoni 2013-03-06 12:11 ` Thierry Reding 2013-03-06 12:11 ` Thierry Reding 2013-03-06 18:09 ` Jason Gunthorpe 2013-03-06 18:09 ` Jason Gunthorpe 2013-03-07 8:08 ` Thierry Reding 2013-03-07 8:08 ` Thierry Reding 2013-03-07 17:49 ` Jason Gunthorpe 2013-03-07 17:49 ` Jason Gunthorpe 2013-03-07 19:48 ` Thierry Reding 2013-03-07 19:48 ` Thierry Reding 2013-03-07 20:02 ` Jason Gunthorpe 2013-03-07 20:02 ` Jason Gunthorpe [not found] ` <20130307200235.GB20695-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-03-07 20:47 ` Thierry Reding 2013-03-07 20:47 ` Thierry Reding 2013-03-07 20:47 ` Thierry Reding 2013-03-08 0:05 ` Rob Herring 2013-03-08 0:05 ` Rob Herring 2013-03-08 7:14 ` Thierry Reding 2013-03-08 7:14 ` Thierry Reding 2013-03-08 16:52 ` Jason Gunthorpe 2013-03-08 16:52 ` Jason Gunthorpe 2013-03-08 19:12 ` Thierry Reding 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 19:43 ` Mitch Bradley 2013-03-08 19:43 ` Mitch Bradley 2013-03-08 20:02 ` Jason Gunthorpe 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-08 20:13 ` Thierry Reding 2013-03-08 20:13 ` Thierry Reding 2013-03-10 15:09 ` Thomas Petazzoni 2013-03-10 15:09 ` Thomas Petazzoni 2013-03-11 8:08 ` Thierry Reding 2013-03-11 8:08 ` Thierry Reding 2013-03-08 23:46 ` Mitch Bradley 2013-03-08 23:46 ` Mitch Bradley 2013-03-08 23:46 ` Mitch Bradley 2013-03-09 1:31 ` Jason Gunthorpe 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 4:52 ` Mitch Bradley 2013-03-10 4:52 ` Mitch Bradley 2013-03-10 6:55 ` Jason Gunthorpe 2013-03-10 6:55 ` Jason Gunthorpe [not found] ` <20130310065539.GA14704-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-03-11 5:46 ` Mitch Bradley 2013-03-11 5:46 ` Mitch Bradley 2013-03-11 5:46 ` Mitch Bradley [not found] ` <513D6F9C.9000100-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2013-03-11 7:46 ` Thierry Reding 2013-03-11 7:46 ` Thierry Reding 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:04 ` Mitch Bradley 2013-03-11 18:04 ` Mitch Bradley 2013-03-11 18:23 ` Jason Gunthorpe 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 19:49 ` Mitch Bradley 2013-03-11 19:49 ` Mitch Bradley 2013-03-11 18:15 ` Jason Gunthorpe 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 21:50 ` Mitch Bradley 2013-03-11 21:50 ` Mitch Bradley 2013-03-11 23:25 ` Jason Gunthorpe 2013-03-11 23:25 ` Jason Gunthorpe [not found] ` <20130311232516.GA13873-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-03-11 23:38 ` Mitch Bradley 2013-03-11 23:38 ` Mitch Bradley 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 7:08 ` Thierry Reding 2013-03-12 7:08 ` Thierry Reding 2013-03-12 15:57 ` Jason Gunthorpe 2013-03-12 15:57 ` Jason Gunthorpe 2013-03-12 20:38 ` Thierry Reding 2013-03-12 20:38 ` Thierry Reding 2013-03-12 21:03 ` Jason Gunthorpe 2013-03-12 21:03 ` Jason Gunthorpe 2013-03-12 21:30 ` Thierry Reding 2013-03-12 21:30 ` Thierry Reding 2013-03-12 22:08 ` Jason Gunthorpe 2013-03-12 22:08 ` Jason Gunthorpe 2013-03-12 23:25 ` Mitch Bradley 2013-03-12 23:25 ` Mitch Bradley 2013-03-12 23:25 ` Mitch Bradley 2013-03-13 8:18 ` Thierry Reding 2013-03-13 8:18 ` Thierry Reding 2013-03-13 8:18 ` Thierry Reding 2013-03-13 17:02 ` Jason Gunthorpe 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:26 ` Thierry Reding 2013-03-13 19:26 ` Thierry Reding 2013-03-13 19:59 ` Jason Gunthorpe 2013-03-13 19:59 ` Jason Gunthorpe 2013-03-13 20:54 ` Thierry Reding 2013-03-13 20:54 ` Thierry Reding 2013-03-13 20:58 ` Mitch Bradley 2013-03-13 20:58 ` Mitch Bradley 2013-03-13 20:58 ` Mitch Bradley 2013-03-13 21:33 ` Thierry Reding 2013-03-13 21:33 ` Thierry Reding 2013-03-13 22:48 ` Mitch Bradley 2013-03-13 22:48 ` Mitch Bradley 2013-03-14 0:43 ` Rob Herring 2013-03-14 0:43 ` Rob Herring 2013-03-14 1:20 ` Mitch Bradley 2013-03-14 1:20 ` Mitch Bradley 2013-03-14 7:11 ` Thierry Reding 2013-03-14 7:11 ` Thierry Reding 2013-03-14 4:56 ` Stephen Warren 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:02 ` Thierry Reding 2013-03-13 22:02 ` Thierry Reding 2013-03-13 22:21 ` Jason Gunthorpe 2013-03-13 22:21 ` Jason Gunthorpe 2013-03-14 9:01 ` Thierry Reding 2013-03-14 9:01 ` Thierry Reding 2013-03-14 9:01 ` Thierry Reding 2013-03-14 17:25 ` Jason Gunthorpe 2013-03-14 17:25 ` Jason Gunthorpe 2013-03-14 20:38 ` Thierry Reding [this message] 2013-03-14 20:38 ` Thierry Reding 2013-03-14 21:05 ` Jason Gunthorpe 2013-03-14 21:05 ` Jason Gunthorpe 2013-03-14 21:10 ` Mitch Bradley 2013-03-14 21:10 ` Mitch Bradley 2013-03-14 21:09 ` Thierry Reding 2013-03-14 21:09 ` Thierry Reding 2013-03-14 21:29 ` Jason Gunthorpe 2013-03-14 21:29 ` Jason Gunthorpe 2013-03-14 21:37 ` Thierry Reding 2013-03-14 21:37 ` Thierry Reding 2013-03-13 22:22 ` Jason Gunthorpe 2013-03-13 22:22 ` Jason Gunthorpe 2013-03-09 8:58 ` Thomas Petazzoni 2013-03-09 8:58 ` Thomas Petazzoni 2013-03-08 23:12 ` Rob Herring 2013-03-08 23:12 ` Rob Herring [not found] ` <513A7044.1020700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2013-03-09 11:10 ` Thierry Reding 2013-03-09 11:10 ` Thierry Reding 2013-03-09 11:10 ` Thierry Reding 2013-03-10 5:04 ` Mitch Bradley 2013-03-10 5:04 ` Mitch Bradley 2013-03-10 5:04 ` Mitch Bradley 2013-03-10 15:06 ` Thomas Petazzoni 2013-03-10 15:06 ` Thomas Petazzoni 2013-03-10 18:33 ` Mitch Bradley 2013-03-10 18:33 ` Mitch Bradley 2013-03-10 18:33 ` Mitch Bradley 2013-02-15 0:36 ` Bjorn Helgaas 2013-02-15 0:36 ` Bjorn Helgaas 2013-02-15 5:06 ` Thomas Petazzoni 2013-02-15 5:06 ` Thomas Petazzoni 2013-02-15 16:26 ` Bjorn Helgaas 2013-02-15 16:26 ` Bjorn Helgaas 2013-02-15 16:44 ` Jason Gunthorpe 2013-02-15 16:44 ` Jason Gunthorpe 2013-02-12 16:28 ` [PATCH 25/32] arm: mvebu: PCIe support is now available on mvebu Thomas Petazzoni 2013-02-12 16:28 ` Thomas Petazzoni 2013-02-12 16:29 ` [PATCH 26/32] arm: mvebu: add PCIe Device Tree informations for Armada 370 Thomas Petazzoni 2013-02-12 16:29 ` Thomas Petazzoni 2013-02-12 16:29 ` [PATCH 27/32] arm: mvebu: add PCIe Device Tree informations for Armada XP Thomas Petazzoni 2013-02-12 16:29 ` Thomas Petazzoni 2013-02-12 16:29 ` [PATCH 28/32] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 Thomas Petazzoni 2013-02-12 16:29 ` Thomas Petazzoni 2013-02-12 16:29 ` [PATCH 29/32] arm: mvebu: PCIe Device Tree informations for Armada XP DB Thomas Petazzoni 2013-02-12 16:29 ` Thomas Petazzoni 2013-02-12 16:29 ` [PATCH 30/32] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox Thomas Petazzoni 2013-02-12 16:29 ` Thomas Petazzoni 2013-02-12 16:29 ` [PATCH 31/32] arm: mvebu: PCIe Device Tree informations for Armada 370 DB Thomas Petazzoni 2013-02-12 16:29 ` Thomas Petazzoni 2013-02-12 16:29 ` [PATCH 32/32] arm: mvebu: update defconfig with PCI and USB support Thomas Petazzoni 2013-02-12 16:29 ` Thomas Petazzoni 2013-02-12 18:12 ` [PATCH v3] PCIe support for the Armada 370 and Armada XP SoCs Arnd Bergmann 2013-02-12 18:12 ` Arnd Bergmann 2013-02-12 19:04 ` Thomas Petazzoni 2013-02-12 19:04 ` Thomas Petazzoni 2013-02-13 8:50 ` Thomas Petazzoni 2013-02-13 8:50 ` Thomas Petazzoni 2013-02-13 9:37 ` Arnd Bergmann 2013-02-13 9:37 ` Arnd Bergmann 2013-02-13 15:27 ` Christophe Vu-Brugier 2013-02-13 15:27 ` Christophe Vu-Brugier 2013-02-13 15:30 ` Thomas Petazzoni 2013-02-13 15:30 ` 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=20130314203858.GA4539@avionic-0098.mockup.avionic-design.de \ --to=thierry.reding@avionic-design.de \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=jgunthorpe@obsidianresearch.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pci@vger.kernel.org \ --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: 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.