From: Andrew Murray <andrew.murray@arm.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>,
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>,
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: Tue, 29 Jan 2013 13:31:40 +0000 [thread overview]
Message-ID: <20130129133140.GA24193@arm.com> (raw)
In-Reply-To: <20130122192901.GE30647@obsidianresearch.com>
On Tue, Jan 22, 2013 at 07:29:01PM +0000, Jason Gunthorpe wrote:
> On Thu, Jan 17, 2013 at 04:22:18PM +0000, 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 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.
>
> Here is a bit of additional info on some MSI stuff..
>
> This can be pretty complex. For instance on hyper transport systems
> the PCI to HT bridge has an MSI controller that maps between PCI and
> HT MSI formats, that mapping is configurable, so technically each
> brige could be considered a MSI controller. Typically the mapping
> controllers are all setup the same so there is not much problem with
> this. However *native* HT devices can (which are super rare) can use a
> different MSI format than PCI devices. From a linux perspective HT is
> just a variant of PCI.
>
> On x86 the MSI is delivered to the CPU APIC complex which converts it
> into a vectored interrupt - part of the value of MSI is that the MSI
> data can vector the interrupt to a specific CPU, or group of CPUs or
> whatever.
>
> Presumably SMP ARMs will evolve similar MSI based interrupt vectoring
> capabilities, and presumably on-chip, non-PCI peripherals will evolve
> options to use MSI as well (ie multi-queue ethernet). So it might be
> worth giving some thought to how things could migrate in that
> direction someday.
>
> I have a bit hacky MSI driver for Kirkwood, this work you have to
> generalize the interface could let me actually upstream it :) The MSI
> is built using the Host2CPU doorbell registers, so it is entirely
> unrelated to the PCI-E RC driver.
>
> However, my use of the MSI driver on kirkwood is to assign MSIs to a
> PCI-E device via non-standard registers, more like an on chip
> peripheral. This is because the Host2CPU doorbell doesn't fit 100%
> perfectly with the standard PCI MSI stuff, and the hardware has funny
> needs.. So an 'allocate a MSI interrupt' API would be snazzy too :)
Thanks for this. I believe Thierry may be working on improving the MSI
API - so perhaps we can see where that takes us.
Andrew Murray
next prev parent reply other threads:[~2013-01-29 13:31 UTC|newest]
Thread overview: 93+ 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 ` [PATCH 01/14] of/pci: Provide support for parsing PCI DT ranges property Thierry Reding
2013-01-11 0:06 ` Stephen Warren
2013-01-11 4:02 ` Thierry Reding
2013-01-09 20:43 ` [PATCH 02/14] of/pci: Add of_pci_get_devfn() function Thierry Reding
2013-01-11 0:09 ` Stephen Warren
2013-01-11 4:06 ` 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 ` [PATCH 04/14] of/pci: Add of_pci_parse_bus_range() function Thierry Reding
2013-01-09 20:43 ` [PATCH 05/14] lib: Add I/O map cache implementation Thierry Reding
2013-01-09 21:19 ` Arnd Bergmann
2013-01-09 21:54 ` Thierry Reding
2013-01-09 22:10 ` Arnd Bergmann
2013-01-09 23:12 ` Stephen Warren
2013-01-09 23:17 ` Jason Gunthorpe
2013-01-10 7:19 ` Thierry Reding
2013-01-10 9:17 ` Arnd Bergmann
2013-01-10 10:25 ` Thierry Reding
2013-01-10 18:20 ` Jason Gunthorpe
2013-01-10 18:55 ` Thierry Reding
2013-01-10 19:03 ` Thierry Reding
2013-01-10 19:24 ` Jason Gunthorpe
2013-01-10 20:20 ` Thierry Reding
2013-01-10 21:06 ` Jason Gunthorpe
2013-01-16 10:18 ` Thierry Reding
2013-01-16 11:25 ` Russell King - ARM Linux
2013-01-16 11:52 ` Thierry Reding
2013-01-10 18:26 ` Arnd Bergmann
2013-01-10 18:57 ` Thierry Reding
2013-01-10 7:10 ` Thierry Reding
2013-01-09 21:28 ` Russell King - ARM Linux
2013-01-09 21:57 ` Thierry Reding
2013-01-09 20:43 ` [PATCH 06/14] ARM: pci: Keep pci_common_init() around after init Thierry Reding
2013-02-05 20:41 ` Thierry Reding
2013-02-06 16:30 ` Russell King - ARM Linux
2013-02-06 19:35 ` Thierry Reding
2013-02-06 8:36 ` Thomas Petazzoni
2013-02-06 16:38 ` Linus Walleij
2013-02-07 0:54 ` Arnd Bergmann
2013-02-06 17:07 ` Linus Walleij
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 ` [PATCH 08/14] ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC Thierry Reding
2013-01-09 20:43 ` [PATCH 09/14] ARM: tegra: Move pmc.h to include/mach Thierry Reding
2013-01-11 0:15 ` Stephen Warren
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 21:22 ` Arnd Bergmann
2013-01-09 21:58 ` Thierry Reding
2013-01-09 22:03 ` Arnd Bergmann
2013-01-10 23:54 ` Stephen Warren
2013-01-11 3:40 ` Thierry Reding
2013-01-11 15:36 ` Arnd Bergmann
2013-01-11 15:45 ` Thierry Reding
2013-01-12 12:36 ` Thierry Reding
2013-01-12 21:12 ` Arnd Bergmann
2013-01-13 9:58 ` Thierry Reding
2013-01-14 9:57 ` Andrew Murray
2013-01-15 12:08 ` Thierry Reding
2013-01-15 12:44 ` Arnd Bergmann
2013-01-15 15:40 ` Andrew Murray
2013-01-15 21:14 ` Thierry Reding
2013-01-16 14:00 ` Arnd Bergmann
2013-01-16 16:17 ` Andrew Murray
2013-01-16 18:31 ` Thierry Reding
2013-01-17 15:42 ` Andrew Murray
2013-01-17 16:05 ` Thierry Reding
2013-01-17 16:22 ` Andrew Murray
2013-01-17 20:30 ` Thierry Reding
2013-01-18 9:18 ` Andrew Murray
2013-01-22 19:29 ` Jason Gunthorpe
2013-01-29 13:31 ` Andrew Murray [this message]
2013-01-11 0:48 ` Stephen Warren
2013-01-11 3:52 ` Thierry Reding
2013-01-11 20:34 ` Stephen Warren
2013-01-18 9:56 ` Andrew Murray
2013-01-18 10:09 ` Thierry Reding
2013-02-13 23:11 ` Thomas Petazzoni
2013-01-09 20:43 ` [PATCH 11/14] ARM: tegra: tamonten: Add PCIe support Thierry Reding
2013-01-09 21:23 ` Arnd Bergmann
2013-01-10 20:21 ` Thierry Reding
2013-01-09 20:43 ` [PATCH 12/14] ARM: tegra: tec: " Thierry Reding
2013-01-11 0:22 ` Stephen Warren
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-10 23:58 ` Stephen Warren
2013-01-09 20:43 ` [PATCH 14/14] ARM: tegra: trimslice: " Thierry Reding
2013-01-10 23:56 ` Stephen Warren
2013-01-11 18:48 ` Thierry Reding
2013-01-09 21:25 ` [PATCH 00/14] Rewrite Tegra PCIe driver Thomas Petazzoni
2013-01-10 6:55 ` Thierry Reding
2013-01-10 8:34 ` Thomas Petazzoni
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=20130129133140.GA24193@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).