From: Andrew Murray <andrew.murray@arm.com> To: Thierry Reding <thierry.reding@avionic-design.de> Cc: Arnd Bergmann <arnd@arndb.de>, Stephen Warren <swarren@wwwdotorg.org>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>, Grant Likely <grant.likely@secretlab.ca>, "rob.herring@calxeda.com" <rob.herring@calxeda.com>, Russell King <linux@arm.linux.org.uk>, Bjorn Helgaas <bhelgaas@google.com>, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, "devicetree-discuss@lists.ozlabs.org" <devicetree-discuss@lists.ozlabs.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org> Subject: Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host Date: Fri, 18 Jan 2013 09:18:47 +0000 [thread overview] Message-ID: <20130118091847.GA7171@arm.com> (raw) In-Reply-To: <20130117203010.GA24584@avionic-0098.adnet.avionic-design.de> On Thu, Jan 17, 2013 at 08:30:10PM +0000, Thierry Reding wrote: > On Thu, Jan 17, 2013 at 04:22:18PM +0000, Andrew Murray wrote: > > On Thu, Jan 17, 2013 at 04:05:02PM +0000, Thierry Reding wrote: > > > On Thu, Jan 17, 2013 at 03:42:36PM +0000, Andrew Murray wrote: > > > > On Wed, Jan 16, 2013 at 06:31:01PM +0000, Thierry Reding wrote: > > > > > Alright, putting the functions into pci_ops doesn't sound like a very > > > > > good idea then. Or perhaps it would make sense for hardware where the > > > > > root complex and the MSI controller are handled by the same driver. > > > > > Basically it could be done as a shortcut and if those are not filled > > > > > in, the drivers could still opt to look up an MSI controller from a > > > > > phandle specified in DT. > > > > > > > > > > Even another alternative would be to keep the functions within the > > > > > struct pci_ops and use generic ones if an external MSI controller is > > > > > used. Just tossing around ideas. > > > > > > > > I think an ideal solution would be for additional logic in drivers/msi.c > > > > (e.g. in functions like msi_capability_init) to determine (based on the > > > > passed in pci_dev) which MSI controller ops to use. I'm not sure the best > > > > way to implement an association between an MSI controller and PCI busses > > > > (I believe arch/sparc does something like this - perhaps there will be > > > > inspiration there). > > > > > > > > As you've pointed out, most RCs will have their own MSI controllers - so > > > > it should be easy to register and associate both together. > > > > > > > > I've submitted my previous work on MSI controller registration, but it > > > > doesn't quite solve this problem - perhaps it can be a starting point? > > > > > > We basically have two cases: > > > > > > - The PCI host bridge contains registers for MSI support. In that case > > > it makes little sense to uncouple the MSI implementation from the > > > host bridge driver. > > > > > > - An MSI controller exists outside of the PCI host bridge. The PCI > > > host bridge would in that case have to lookup an MSI controller (via > > > DT phandle or some other method). > > > > > > In either of those cases, does it make sense to use the MSI support > > > outside the scope of the PCI infrastructure? That is, would devices > > > other than PCI devices be able to generate an MSI? > > > > I've come around to your way of thinking. Your approach sounds good for > > registration of MSI ops - let the RC host driver do it (it probably has its > > own), or use a helper for following a phandle to get ops that are not part > > of the driver. MSIs won't be used outside of PCI devices. > > > > Though existing drivers will use MSI framework functions to request MSIs, that > > will result in callbacks to the arch_setup_msi_irqs type functions. These > > functions would need to be updated to find these new ops if they exist, i.e. by > > traversing the pci_dev structure up to the RC and finding a suitable structure. > > > > Perhaps the msi ops could live alongside pci_ops in the pci_bus structure. This > > way when traversing up the buses from the provided pci_dev - the first bus with > > msi ops populated would be used? > > > > If no ops are found, the standard arch callbacks can be called - thus preserving > > exiting functionality. > > Yes, what you describe is exactly what I had in mind. I've been thinking > about a possible implementation and there may be some details that could > prove difficult to resolve. For instance, we likely need to pass context > around for the MSI ops, or else make sure that they can find the context > from the struct pci_dev or by traversing upwards from it. > > I think for the case where the MSI hardware is controlled by the same > driver as the PCI host bridge, doing this is easy because the context > could be part of the PCI host bridge context, which in case of Tegra is > stored in struct pci_bus' sysdata field (which is actually an ARM struct > pci_sys_data and in turn stores a pointer to the struct tegra_pcie in > the .private_data field). Other drivers often just use a global variable > assuming that there will only ever be a single instance of the PCI host > bridge. Yes. > If the MSI controller is external to the PCI host bridge, things get a > little more complicated. The easiest way would probably be to store the > context along with the PCI host bridge context and use simple wrappers > around the actual implementations to retrieve the PHB context and pass > the attached MSI context. This would be nice, but may not be necessary. The MSI controller could use a global (file-scope) variable to hold context gained from its probe and assume it will be the only instance of that MSI controller. > > Maybe this could even be made more generic by adding a struct msi_ops * > along with a struct msi_chip * in struct pci_bus. Perhaps I should try > and code something up to make things more concrete. This would be the most complete way to handle this. Andrew Murray
WARNING: multiple messages have this Message-ID (diff)
From: andrew.murray@arm.com (Andrew Murray) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host Date: Fri, 18 Jan 2013 09:18:47 +0000 [thread overview] Message-ID: <20130118091847.GA7171@arm.com> (raw) In-Reply-To: <20130117203010.GA24584@avionic-0098.adnet.avionic-design.de> On Thu, Jan 17, 2013 at 08:30:10PM +0000, Thierry Reding wrote: > On Thu, Jan 17, 2013 at 04:22:18PM +0000, Andrew Murray wrote: > > On Thu, Jan 17, 2013 at 04:05:02PM +0000, Thierry Reding wrote: > > > On Thu, Jan 17, 2013 at 03:42:36PM +0000, Andrew Murray wrote: > > > > On Wed, Jan 16, 2013 at 06:31:01PM +0000, Thierry Reding wrote: > > > > > Alright, putting the functions into pci_ops doesn't sound like a very > > > > > good idea then. Or perhaps it would make sense for hardware where the > > > > > root complex and the MSI controller are handled by the same driver. > > > > > Basically it could be done as a shortcut and if those are not filled > > > > > in, the drivers could still opt to look up an MSI controller from a > > > > > phandle specified in DT. > > > > > > > > > > Even another alternative would be to keep the functions within the > > > > > struct pci_ops and use generic ones if an external MSI controller is > > > > > used. Just tossing around ideas. > > > > > > > > I think an ideal solution would be for additional logic in drivers/msi.c > > > > (e.g. in functions like msi_capability_init) to determine (based on the > > > > passed in pci_dev) which MSI controller ops to use. I'm not sure the best > > > > way to implement an association between an MSI controller and PCI busses > > > > (I believe arch/sparc does something like this - perhaps there will be > > > > inspiration there). > > > > > > > > As you've pointed out, most RCs will have their own MSI controllers - so > > > > it should be easy to register and associate both together. > > > > > > > > I've submitted my previous work on MSI controller registration, but it > > > > doesn't quite solve this problem - perhaps it can be a starting point? > > > > > > We basically have two cases: > > > > > > - The PCI host bridge contains registers for MSI support. In that case > > > it makes little sense to uncouple the MSI implementation from the > > > host bridge driver. > > > > > > - An MSI controller exists outside of the PCI host bridge. The PCI > > > host bridge would in that case have to lookup an MSI controller (via > > > DT phandle or some other method). > > > > > > In either of those cases, does it make sense to use the MSI support > > > outside the scope of the PCI infrastructure? That is, would devices > > > other than PCI devices be able to generate an MSI? > > > > I've come around to your way of thinking. Your approach sounds good for > > registration of MSI ops - let the RC host driver do it (it probably has its > > own), or use a helper for following a phandle to get ops that are not part > > of the driver. MSIs won't be used outside of PCI devices. > > > > Though existing drivers will use MSI framework functions to request MSIs, that > > will result in callbacks to the arch_setup_msi_irqs type functions. These > > functions would need to be updated to find these new ops if they exist, i.e. by > > traversing the pci_dev structure up to the RC and finding a suitable structure. > > > > Perhaps the msi ops could live alongside pci_ops in the pci_bus structure. This > > way when traversing up the buses from the provided pci_dev - the first bus with > > msi ops populated would be used? > > > > If no ops are found, the standard arch callbacks can be called - thus preserving > > exiting functionality. > > Yes, what you describe is exactly what I had in mind. I've been thinking > about a possible implementation and there may be some details that could > prove difficult to resolve. For instance, we likely need to pass context > around for the MSI ops, or else make sure that they can find the context > from the struct pci_dev or by traversing upwards from it. > > I think for the case where the MSI hardware is controlled by the same > driver as the PCI host bridge, doing this is easy because the context > could be part of the PCI host bridge context, which in case of Tegra is > stored in struct pci_bus' sysdata field (which is actually an ARM struct > pci_sys_data and in turn stores a pointer to the struct tegra_pcie in > the .private_data field). Other drivers often just use a global variable > assuming that there will only ever be a single instance of the PCI host > bridge. Yes. > If the MSI controller is external to the PCI host bridge, things get a > little more complicated. The easiest way would probably be to store the > context along with the PCI host bridge context and use simple wrappers > around the actual implementations to retrieve the PHB context and pass > the attached MSI context. This would be nice, but may not be necessary. The MSI controller could use a global (file-scope) variable to hold context gained from its probe and assume it will be the only instance of that MSI controller. > > Maybe this could even be made more generic by adding a struct msi_ops * > along with a struct msi_chip * in struct pci_bus. Perhaps I should try > and code something up to make things more concrete. This would be the most complete way to handle this. Andrew Murray
next prev parent reply other threads:[~2013-01-18 9:18 UTC|newest] Thread overview: 267+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-09 20:43 [PATCH 00/14] Rewrite Tegra PCIe driver Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 02/14] of/pci: Add of_pci_get_devfn() function Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-3-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-11 0:09 ` Stephen Warren 2013-01-11 0:09 ` Stephen Warren 2013-01-11 0:09 ` Stephen Warren 2013-01-11 4:06 ` Thierry Reding 2013-01-11 4:06 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 05/14] lib: Add I/O map cache implementation Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-6-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-09 21:19 ` Arnd Bergmann 2013-01-09 21:19 ` Arnd Bergmann 2013-01-09 21:19 ` Arnd Bergmann 2013-01-09 21:54 ` Thierry Reding 2013-01-09 21:54 ` Thierry Reding [not found] ` <20130109215428.GA13648-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-09 22:10 ` Arnd Bergmann 2013-01-09 22:10 ` Arnd Bergmann 2013-01-09 22:10 ` Arnd Bergmann [not found] ` <201301092210.49452.arnd-r2nGTMty4D4@public.gmane.org> 2013-01-09 23:12 ` Stephen Warren 2013-01-09 23:12 ` Stephen Warren 2013-01-09 23:12 ` Stephen Warren 2013-01-09 23:17 ` Jason Gunthorpe 2013-01-09 23:17 ` Jason Gunthorpe [not found] ` <20130109231758.GA27065-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-01-10 7:19 ` Thierry Reding 2013-01-10 7:19 ` Thierry Reding 2013-01-10 7:19 ` Thierry Reding [not found] ` <20130110071937.GG15212-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-10 9:17 ` Arnd Bergmann 2013-01-10 9:17 ` Arnd Bergmann 2013-01-10 9:17 ` Arnd Bergmann [not found] ` <201301100917.19577.arnd-r2nGTMty4D4@public.gmane.org> 2013-01-10 10:25 ` Thierry Reding 2013-01-10 10:25 ` Thierry Reding 2013-01-10 10:25 ` Thierry Reding [not found] ` <20130110102544.GA5546-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-10 18:20 ` Jason Gunthorpe 2013-01-10 18:20 ` Jason Gunthorpe 2013-01-10 18:20 ` Jason Gunthorpe [not found] ` <20130110182007.GA28004-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-01-10 18:55 ` Thierry Reding 2013-01-10 18:55 ` Thierry Reding 2013-01-10 18:55 ` Thierry Reding 2013-01-10 19:03 ` Thierry Reding 2013-01-10 19:03 ` Thierry Reding 2013-01-10 19:24 ` Jason Gunthorpe 2013-01-10 19:24 ` Jason Gunthorpe [not found] ` <20130110192417.GA18478-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-01-10 20:20 ` Thierry Reding 2013-01-10 20:20 ` Thierry Reding 2013-01-10 20:20 ` Thierry Reding [not found] ` <20130110202007.GA26139-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-10 21:06 ` Jason Gunthorpe 2013-01-10 21:06 ` Jason Gunthorpe 2013-01-10 21:06 ` Jason Gunthorpe 2013-01-16 10:18 ` Thierry Reding 2013-01-16 10:18 ` Thierry Reding 2013-01-16 10:18 ` Thierry Reding [not found] ` <20130116101822.GA17706-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-16 11:25 ` Russell King - ARM Linux 2013-01-16 11:25 ` Russell King - ARM Linux 2013-01-16 11:25 ` Russell King - ARM Linux [not found] ` <20130116112556.GR23505-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-01-16 11:52 ` Thierry Reding 2013-01-16 11:52 ` Thierry Reding 2013-01-16 11:52 ` Thierry Reding 2013-01-10 18:26 ` Arnd Bergmann 2013-01-10 18:26 ` Arnd Bergmann 2013-01-10 18:26 ` Arnd Bergmann [not found] ` <201301101826.56248.arnd-r2nGTMty4D4@public.gmane.org> 2013-01-10 18:57 ` Thierry Reding 2013-01-10 18:57 ` Thierry Reding 2013-01-10 18:57 ` Thierry Reding 2013-01-10 7:10 ` Thierry Reding 2013-01-10 7:10 ` Thierry Reding 2013-01-10 7:10 ` Thierry Reding 2013-01-09 21:28 ` Russell King - ARM Linux 2013-01-09 21:28 ` Russell King - ARM Linux 2013-01-09 21:28 ` Russell King - ARM Linux [not found] ` <20130109212847.GT3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-01-09 21:57 ` Thierry Reding 2013-01-09 21:57 ` Thierry Reding 2013-01-09 21:57 ` Thierry Reding [not found] ` <1357764194-12677-1-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-09 20:43 ` [PATCH 01/14] of/pci: Provide support for parsing PCI DT ranges property Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-11 0:06 ` Stephen Warren 2013-01-11 0:06 ` Stephen Warren [not found] ` <50EF5798.6040405-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-01-11 4:02 ` Thierry Reding 2013-01-11 4:02 ` Thierry Reding 2013-01-11 4:02 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 03/14] of/pci: Add of_pci_get_bus() function Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 04/14] of/pci: Add of_pci_parse_bus_range() function Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-7-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-02-05 20:41 ` Thierry Reding 2013-02-05 20:41 ` Thierry Reding 2013-02-05 20:41 ` Thierry Reding [not found] ` <20130205204147.GA29726-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org> 2013-02-06 16:30 ` Russell King - ARM Linux 2013-02-06 16:30 ` Russell King - ARM Linux 2013-02-06 16:30 ` Russell King - ARM Linux [not found] ` <20130206163041.GG17833-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-02-06 19:35 ` Thierry Reding 2013-02-06 19:35 ` Thierry Reding 2013-02-06 19:35 ` Thierry Reding 2013-02-06 8:36 ` Thomas Petazzoni 2013-02-06 8:36 ` Thomas Petazzoni 2013-02-06 8:36 ` Thomas Petazzoni 2013-02-06 16:38 ` Linus Walleij 2013-02-06 16:38 ` Linus Walleij 2013-02-06 16:38 ` Linus Walleij 2013-02-07 0:54 ` Arnd Bergmann 2013-02-07 0:54 ` Arnd Bergmann 2013-02-06 17:07 ` Linus Walleij 2013-02-06 17:07 ` Linus Walleij 2013-02-06 17:07 ` Linus Walleij 2013-02-07 1:20 ` Arnd Bergmann 2013-02-07 1:20 ` Arnd Bergmann 2013-02-07 1:20 ` Arnd Bergmann 2013-01-09 20:43 ` [PATCH 07/14] ARM: pci: Allow passing per-controller private data Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 08/14] ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 11/14] ARM: tegra: tamonten: Add PCIe support Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-12-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-09 21:23 ` Arnd Bergmann 2013-01-09 21:23 ` Arnd Bergmann 2013-01-09 21:23 ` Arnd Bergmann [not found] ` <201301092123.37491.arnd-r2nGTMty4D4@public.gmane.org> 2013-01-10 20:21 ` Thierry Reding 2013-01-10 20:21 ` Thierry Reding 2013-01-10 20:21 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 14/14] ARM: tegra: trimslice: Initialize PCIe from DT Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-15-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-10 23:56 ` Stephen Warren 2013-01-10 23:56 ` Stephen Warren 2013-01-10 23:56 ` Stephen Warren [not found] ` <50EF5537.6080602-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-01-11 18:48 ` Thierry Reding 2013-01-11 18:48 ` Thierry Reding 2013-01-11 18:48 ` Thierry Reding 2013-01-09 21:25 ` [PATCH 00/14] Rewrite Tegra PCIe driver Thomas Petazzoni 2013-01-09 21:25 ` Thomas Petazzoni 2013-01-09 21:25 ` Thomas Petazzoni 2013-01-10 6:55 ` Thierry Reding 2013-01-10 6:55 ` Thierry Reding 2013-01-10 6:55 ` Thierry Reding 2013-01-10 8:34 ` Thomas Petazzoni 2013-01-10 8:34 ` Thomas Petazzoni 2013-03-06 18:16 ` Murali Karicheri 2013-01-09 20:43 ` [PATCH 09/14] ARM: tegra: Move pmc.h to include/mach Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-10-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-11 0:15 ` Stephen Warren 2013-01-11 0:15 ` Stephen Warren 2013-01-11 0:15 ` Stephen Warren [not found] ` <50EF598B.2030307-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-01-11 4:08 ` Thierry Reding 2013-01-11 4:08 ` Thierry Reding 2013-01-11 4:08 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-11-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-09 21:22 ` Arnd Bergmann 2013-01-09 21:22 ` Arnd Bergmann 2013-01-09 21:22 ` Arnd Bergmann [not found] ` <201301092122.08011.arnd-r2nGTMty4D4@public.gmane.org> 2013-01-09 21:58 ` Thierry Reding 2013-01-09 21:58 ` Thierry Reding 2013-01-09 21:58 ` Thierry Reding 2013-01-09 22:03 ` Arnd Bergmann 2013-01-09 22:03 ` Arnd Bergmann 2013-01-11 0:48 ` Stephen Warren 2013-01-11 0:48 ` Stephen Warren 2013-01-11 0:48 ` Stephen Warren [not found] ` <50EF616E.7040609-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-01-11 3:52 ` Thierry Reding 2013-01-11 3:52 ` Thierry Reding 2013-01-11 3:52 ` Thierry Reding 2013-01-11 20:34 ` Stephen Warren 2013-01-11 20:34 ` Stephen Warren 2013-02-13 23:11 ` Thomas Petazzoni 2013-02-13 23:11 ` Thomas Petazzoni 2013-02-13 23:11 ` Thomas Petazzoni 2013-01-10 23:54 ` Stephen Warren 2013-01-10 23:54 ` Stephen Warren 2013-01-11 3:40 ` Thierry Reding 2013-01-11 3:40 ` Thierry Reding [not found] ` <20130111034015.GA28094-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-11 15:36 ` Arnd Bergmann 2013-01-11 15:36 ` Arnd Bergmann 2013-01-11 15:36 ` Arnd Bergmann [not found] ` <201301111536.14799.arnd-r2nGTMty4D4@public.gmane.org> 2013-01-11 15:45 ` Thierry Reding 2013-01-11 15:45 ` Thierry Reding 2013-01-11 15:45 ` Thierry Reding [not found] ` <20130111154516.GA25335-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-12 12:36 ` Thierry Reding 2013-01-12 12:36 ` Thierry Reding 2013-01-12 12:36 ` Thierry Reding 2013-01-12 21:12 ` Arnd Bergmann 2013-01-12 21:12 ` Arnd Bergmann 2013-01-13 9:58 ` Thierry Reding 2013-01-13 9:58 ` Thierry Reding [not found] ` <20130113095806.GA31966-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org> 2013-01-14 9:57 ` Andrew Murray 2013-01-14 9:57 ` Andrew Murray 2013-01-14 9:57 ` Andrew Murray 2013-01-14 9:57 ` Andrew Murray [not found] ` <20130114095706.GA23467-5wv7dgnIgG8@public.gmane.org> 2013-01-15 12:08 ` Thierry Reding 2013-01-15 12:08 ` Thierry Reding 2013-01-15 12:08 ` Thierry Reding 2013-01-15 12:08 ` Thierry Reding 2013-01-15 12:44 ` Arnd Bergmann 2013-01-15 12:44 ` Arnd Bergmann 2013-01-15 12:44 ` Arnd Bergmann [not found] ` <201301151244.12767.arnd-r2nGTMty4D4@public.gmane.org> 2013-01-15 15:40 ` Andrew Murray 2013-01-15 15:40 ` Andrew Murray 2013-01-15 15:40 ` Andrew Murray 2013-01-15 15:40 ` Andrew Murray [not found] ` <20130115154038.GA11241-5wv7dgnIgG8@public.gmane.org> 2013-01-15 21:14 ` Thierry Reding 2013-01-15 21:14 ` Thierry Reding 2013-01-15 21:14 ` Thierry Reding 2013-01-15 21:14 ` Thierry Reding 2013-01-16 14:00 ` Arnd Bergmann 2013-01-16 14:00 ` Arnd Bergmann 2013-01-16 14:00 ` Arnd Bergmann 2013-01-16 16:17 ` Andrew Murray 2013-01-16 16:17 ` Andrew Murray 2013-01-16 16:17 ` Andrew Murray 2013-01-16 18:31 ` Thierry Reding 2013-01-16 18:31 ` Thierry Reding 2013-01-16 18:31 ` Thierry Reding 2013-01-17 15:42 ` Andrew Murray 2013-01-17 15:42 ` Andrew Murray 2013-01-17 15:42 ` Andrew Murray [not found] ` <20130117154236.GA25943-5wv7dgnIgG8@public.gmane.org> 2013-01-17 16:05 ` Thierry Reding 2013-01-17 16:05 ` Thierry Reding 2013-01-17 16:05 ` Thierry Reding 2013-01-17 16:05 ` Thierry Reding 2013-01-17 16:22 ` Andrew Murray 2013-01-17 16:22 ` Andrew Murray 2013-01-17 16:22 ` Andrew Murray [not found] ` <20130117162218.GA29016-5wv7dgnIgG8@public.gmane.org> 2013-01-17 20:30 ` Thierry Reding 2013-01-17 20:30 ` Thierry Reding 2013-01-17 20:30 ` Thierry Reding 2013-01-17 20:30 ` Thierry Reding 2013-01-18 9:18 ` Andrew Murray [this message] 2013-01-18 9:18 ` Andrew Murray 2013-01-18 9:18 ` Andrew Murray 2013-01-22 19:29 ` Jason Gunthorpe 2013-01-22 19:29 ` Jason Gunthorpe 2013-01-22 19:29 ` Jason Gunthorpe 2013-01-22 19:29 ` Jason Gunthorpe 2013-01-29 13:31 ` Andrew Murray 2013-01-29 13:31 ` Andrew Murray 2013-01-29 13:31 ` Andrew Murray 2013-01-18 9:56 ` Andrew Murray 2013-01-18 9:56 ` Andrew Murray 2013-01-18 9:56 ` Andrew Murray [not found] ` <20130118095620.GA7552-5wv7dgnIgG8@public.gmane.org> 2013-01-18 10:09 ` Thierry Reding 2013-01-18 10:09 ` Thierry Reding 2013-01-18 10:09 ` Thierry Reding 2013-01-18 10:09 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 12/14] ARM: tegra: tec: Add PCIe support Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-13-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-11 0:22 ` Stephen Warren 2013-01-11 0:22 ` Stephen Warren 2013-01-11 0:22 ` Stephen Warren 2013-01-11 4:34 ` Thierry Reding 2013-01-11 4:34 ` Thierry Reding 2013-01-09 20:43 ` [PATCH 13/14] ARM: tegra: harmony: Initialize PCIe from DT Thierry Reding 2013-01-09 20:43 ` Thierry Reding 2013-01-09 20:43 ` Thierry Reding [not found] ` <1357764194-12677-14-git-send-email-thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> 2013-01-10 23:58 ` Stephen Warren 2013-01-10 23:58 ` Stephen Warren 2013-01-10 23:58 ` Stephen Warren 2013-01-28 18:15 ` [PATCH 00/14] Rewrite Tegra PCIe driver Bjorn Helgaas 2013-01-28 18:15 ` Bjorn Helgaas
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=20130118091847.GA7171@arm.com \ --to=andrew.murray@arm.com \ --cc=arnd@arndb.de \ --cc=bhelgaas@google.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=grant.likely@secretlab.ca \ --cc=jgunthorpe@obsidianresearch.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux-tegra@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=rob.herring@calxeda.com \ --cc=swarren@wwwdotorg.org \ --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.