Dear Grant Likely,
On Wed, 13 Feb 2013 22:59:50 +, Grant Likely wrote:
> There isn't a whole lot of value in this patch without another user.
> I'll need to see the other patches that make use of this.
See the proposed Marvell PCIe driver and Tegra PCIe driver:
http://lists.infradead.org/pi
On Tue, Jan 22, 2013 at 07:29:01PM +, Jason Gunthorpe wrote:
> On Thu, Jan 17, 2013 at 04:22:18PM +, Andrew Murray wrote:
>
> > > 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 P
On Thu, Jan 17, 2013 at 04:22:18PM +, Andrew Murray wrote:
> > 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
On Fri, Jan 18, 2013 at 09:56:20AM +, Andrew Murray wrote:
> On Wed, Jan 09, 2013 at 08:43:10PM +, Thierry Reding wrote:
> > Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> > directory. The motivation is to collect various host controller drivers
> > in the same lo
On Wed, Jan 09, 2013 at 08:43:10PM +, Thierry Reding wrote:
> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> directory. The motivation is to collect various host controller drivers
> in the same location in order to facilitate refactoring.
>
> The Tegra PCIe driver h
On Thu, Jan 17, 2013 at 08:30:10PM +, Thierry Reding wrote:
> On Thu, Jan 17, 2013 at 04:22:18PM +, Andrew Murray wrote:
> > On Thu, Jan 17, 2013 at 04:05:02PM +, Thierry Reding wrote:
> > > On Thu, Jan 17, 2013 at 03:42:36PM +, Andrew Murray wrote:
> > > > On Wed, Jan 16, 2013 at 0
On Thu, Jan 17, 2013 at 04:22:18PM +, Andrew Murray wrote:
> On Thu, Jan 17, 2013 at 04:05:02PM +, Thierry Reding wrote:
> > On Thu, Jan 17, 2013 at 03:42:36PM +, Andrew Murray wrote:
> > > On Wed, Jan 16, 2013 at 06:31:01PM +, Thierry Reding wrote:
> > > > Alright, putting the func
On Thu, Jan 17, 2013 at 04:05:02PM +, Thierry Reding wrote:
> On Thu, Jan 17, 2013 at 03:42:36PM +, Andrew Murray wrote:
> > On Wed, Jan 16, 2013 at 06:31:01PM +, Thierry Reding wrote:
> > > Alright, putting the functions into pci_ops doesn't sound like a very
> > > good idea then. Or p
On Thu, Jan 17, 2013 at 03:42:36PM +, Andrew Murray wrote:
> On Wed, Jan 16, 2013 at 06:31:01PM +, 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 t
On Wed, Jan 16, 2013 at 06:31:01PM +, 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
On Wed, Jan 16, 2013 at 04:17:16PM +, Andrew Murray wrote:
> On Wed, Jan 16, 2013 at 02:00:26PM +, Arnd Bergmann wrote:
> > On Tuesday 15 January 2013, Thierry Reding wrote:
> > > Is there actually hardware that supports this? I assumed that the MSI
> > > controller would have to be tightly
On Wed, Jan 16, 2013 at 02:00:26PM +, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Thierry Reding wrote:
> > Is there actually hardware that supports this? I assumed that the MSI
> > controller would have to be tightly coupled to the PCI host bridge in
> > order to raise an interrupt when
On Tuesday 15 January 2013, Thierry Reding wrote:
> Is there actually hardware that supports this? I assumed that the MSI
> controller would have to be tightly coupled to the PCI host bridge in
> order to raise an interrupt when an MSI is received via PCI.
No, as long as it's guaranteed that the M
On Tue, Jan 15, 2013 at 03:40:38PM +, Andrew Murray wrote:
> On Tue, Jan 15, 2013 at 12:44:12PM +, Arnd Bergmann wrote:
> > On Tuesday 15 January 2013, Thierry Reding wrote:
> > > I'm not sure I follow you're reasoning here. Is it possible to use MSIs
> > > without PCI? If not then I think
On Tue, Jan 15, 2013 at 12:44:12PM +, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Thierry Reding wrote:
> > I'm not sure I follow you're reasoning here. Is it possible to use MSIs
> > without PCI? If not then I think there's little sense in keeping the
> > implementations separate.
>
>
On Tuesday 15 January 2013, Thierry Reding wrote:
> I'm not sure I follow you're reasoning here. Is it possible to use MSIs
> without PCI? If not then I think there's little sense in keeping the
> implementations separate.
Conceptually, you can use MSI for any device, but the Linux interfaces
for
On Mon, Jan 14, 2013 at 09:57:07AM +, Andrew Murray wrote:
> On Sun, Jan 13, 2013 at 09:58:06AM +, Thierry Reding wrote:
> > On Sat, Jan 12, 2013 at 09:12:25PM +, Arnd Bergmann wrote:
> > > On Saturday 12 January 2013, Thierry Reding wrote:
> > > > > I already hinted at that in one of t
On Sun, Jan 13, 2013 at 09:58:06AM +, Thierry Reding wrote:
> On Sat, Jan 12, 2013 at 09:12:25PM +, Arnd Bergmann wrote:
> > On Saturday 12 January 2013, Thierry Reding wrote:
> > > > I already hinted at that in one of the other subthreads. Having such a
> > > > multiplex would also allow t
On Sat, Jan 12, 2013 at 09:12:25PM +, Arnd Bergmann wrote:
> On Saturday 12 January 2013, Thierry Reding wrote:
> > > I already hinted at that in one of the other subthreads. Having such a
> > > multiplex would also allow the driver to be built as a module. I had
> > > already thought about thi
On Saturday 12 January 2013, Thierry Reding wrote:
> > I already hinted at that in one of the other subthreads. Having such a
> > multiplex would also allow the driver to be built as a module. I had
> > already thought about this when I was working on an earlier version of
> > these patches. Basica
On Fri, Jan 11, 2013 at 04:45:16PM +0100, Thierry Reding wrote:
> On Fri, Jan 11, 2013 at 03:36:14PM +, Arnd Bergmann wrote:
> > On Friday 11 January 2013, Thierry Reding wrote:
> > > Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
> > > select PCI_MSI unconditionally.
On 01/10/2013 08:52 PM, Thierry Reding wrote:
> On Thu, Jan 10, 2013 at 05:48:46PM -0700, Stephen Warren wrote:
>> On 01/09/2013 01:43 PM, Thierry Reding wrote:
>>> Move the PCIe driver from arch/arm/mach-tegra into the
>>> drivers/pci/host directory. The motivation is to collect
>>> various host c
On Fri, Jan 11, 2013 at 03:36:14PM +, Arnd Bergmann wrote:
> On Friday 11 January 2013, Thierry Reding wrote:
> > Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
> > select PCI_MSI unconditionally. Once this is merged I was going to post
> > a patch that enables PCI_MSI
On Friday 11 January 2013, Thierry Reding wrote:
> Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
> select PCI_MSI unconditionally. Once this is merged I was going to post
> a patch that enables PCI_MSI in tegra_defconfig anyway. But it might be
> better to keep it optiona
On Thu, Jan 10, 2013 at 05:48:46PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> > directory. The motivation is to collect various host controller drivers
> > in the same location in order t
On Thu, Jan 10, 2013 at 04:54:30PM -0700, Stephen Warren wrote:
> On 01/09/2013 01:43 PM, Thierry Reding wrote:
> > Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> > directory. The motivation is to collect various host controller drivers
> > in the same location in order t
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> directory. The motivation is to collect various host controller drivers
> in the same location in order to facilitate refactoring.
>
> The Tegra PCIe driver has been largely re
On 01/09/2013 01:43 PM, Thierry Reding wrote:
> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> directory. The motivation is to collect various host controller drivers
> in the same location in order to facilitate refactoring.
>
> The Tegra PCIe driver has been largely re
On Wednesday 09 January 2013, Thierry Reding wrote:
> Stephen suggested I post this as removal/addition because pretty much
> everything changed. Reviewing the individual changes would be more
> confusing than actually reviewing a new driver.
>
Ok, fair enough.
Arnd
--
To unsubscribe fro
On Wed, Jan 09, 2013 at 09:22:07PM +, Arnd Bergmann wrote:
> On Wednesday 09 January 2013, Thierry Reding wrote:
> > Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> > directory. The motivation is to collect various host controller drivers
> > in the same location in or
On Wednesday 09 January 2013, Thierry Reding wrote:
> Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
> directory. The motivation is to collect various host controller drivers
> in the same location in order to facilitate refactoring.
>
> The Tegra PCIe driver has been larg
31 matches
Mail list logo
