Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1214919 > unrolled thread

[RFC PATCH 1/2] x86: PCI bus specific MSI operations

Started byKeith Busch <keith.busch@intel.com>
First post2015-08-28 00:40 +0200
Last post2015-08-29 03:50 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [RFC PATCH 1/2] x86: PCI bus specific MSI operations Keith Busch <keith.busch@intel.com> - 2015-08-28 00:40 +0200
    Re: [RFC PATCH 1/2] x86: PCI bus specific MSI operations Thomas Gleixner <tglx@linutronix.de> - 2015-08-28 19:00 +0200
      Re: [RFC PATCH 1/2] x86: PCI bus specific MSI operations Keith Busch <keith.busch@intel.com> - 2015-08-28 23:40 +0200
      Re: [RFC PATCH 1/2] x86: PCI bus specific MSI operations Jiang Liu <jiang.liu@linux.intel.com> - 2015-08-29 03:50 +0200

#1214919 — [RFC PATCH 1/2] x86: PCI bus specific MSI operations

FromKeith Busch <keith.busch@intel.com>
Date2015-08-28 00:40 +0200
Subject[RFC PATCH 1/2] x86: PCI bus specific MSI operations
Message-ID<q2dZV-1aQ-39@gated-at.bofh.it>
This patch adds struct x86_msi_ops to x86's PCI sysdata. This gives a
host bridge driver the option to provide alternate MSI Data Register
and MSI-X Table Entry programming for devices in PCI domains that do
not subscribe to usual "IOAPIC" format.

Signed-off-by: Keith Busch <keith.busch@intel.com>
CC: Bryan Veal <bryan.e.veal@intel.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: x86@kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux-pci@vger.kernel.org
---
 arch/x86/include/asm/pci.h |    3 +++
 arch/x86/kernel/x86_init.c |   19 +++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..98f3802 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -20,6 +20,9 @@ struct pci_sysdata {
 #ifdef CONFIG_X86_64
 	void		*iommu;		/* IOMMU private data */
 #endif
+#ifdef CONFIG_PCI_MSI
+	struct x86_msi_ops *msi_ops;
+#endif
 };
 
 extern int pci_routeirq;
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 3839628..416de84 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -118,21 +118,40 @@ struct x86_msi_ops x86_msi = {
 /* MSI arch specific hooks */
 int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 {
+	struct pci_sysdata *sysdata = dev->bus->sysdata;
+
+	if (sysdata && sysdata->msi_ops && sysdata->msi_ops->setup_msi_irqs)
+		return sysdata->msi_ops->setup_msi_irqs(dev, nvec, type);
 	return x86_msi.setup_msi_irqs(dev, nvec, type);
 }
 
 void arch_teardown_msi_irqs(struct pci_dev *dev)
 {
+	struct pci_sysdata *sysdata = dev->bus->sysdata;
+
+	if (sysdata && sysdata->msi_ops && sysdata->msi_ops->teardown_msi_irqs)
+		return sysdata->msi_ops->teardown_msi_irqs(dev);
 	x86_msi.teardown_msi_irqs(dev);
 }
 
 void arch_teardown_msi_irq(unsigned int irq)
 {
+	struct msi_desc *desc =  irq_get_msi_desc(irq);
+	struct pci_sysdata *sysdata = NULL;
+
+	if (desc)
+		sysdata = desc->dev->bus->sysdata;
+	if (sysdata && sysdata->msi_ops && sysdata->msi_ops->teardown_msi_irq)
+		return sysdata->msi_ops->teardown_msi_irq(irq);
 	x86_msi.teardown_msi_irq(irq);
 }
 
 void arch_restore_msi_irqs(struct pci_dev *dev)
 {
+	struct pci_sysdata *sysdata = dev->bus->sysdata;
+
+	if (sysdata && sysdata->msi_ops && sysdata->msi_ops->restore_msi_irqs)
+		return sysdata->msi_ops->restore_msi_irqs(dev);
 	x86_msi.restore_msi_irqs(dev);
 }
 #endif
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1215447

FromThomas Gleixner <tglx@linutronix.de>
Date2015-08-28 19:00 +0200
Message-ID<q2var-FH-27@gated-at.bofh.it>
In reply to#1214919
On Thu, 27 Aug 2015, Keith Busch wrote:

> This patch adds struct x86_msi_ops to x86's PCI sysdata. This gives a
> host bridge driver the option to provide alternate MSI Data Register
> and MSI-X Table Entry programming for devices in PCI domains that do
> not subscribe to usual "IOAPIC" format.

I'm not too fond about more ad hoc indirection and special casing. We
should be able to handle this with hierarchical irq domains. Jiang
might have an idea how to do that for your case.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1215573

FromKeith Busch <keith.busch@intel.com>
Date2015-08-28 23:40 +0200
Message-ID<q2zxn-6Zc-7@gated-at.bofh.it>
In reply to#1215447
On Fri, 28 Aug 2015, Thomas Gleixner wrote:
> On Thu, 27 Aug 2015, Keith Busch wrote:
>
>> This patch adds struct x86_msi_ops to x86's PCI sysdata. This gives a
>> host bridge driver the option to provide alternate MSI Data Register
>> and MSI-X Table Entry programming for devices in PCI domains that do
>> not subscribe to usual "IOAPIC" format.
>
> I'm not too fond about more ad hoc indirection and special casing. We
> should be able to handle this with hierarchical irq domains. Jiang
> might have an idea how to do that for your case.

Thank you for the suggestion, I will take a closer look at this again. All
the better if we don't require an arch specific dependency.

I asked Jiang about domain hierarchies a few weeks ago and understood
these are suited for irq controllers, but the VMD device is an aggregator.

Here's a little more h/w info in case it helps steer me in the right
direction: VMD muxes all the device interrupts in its PCI domain into
one of several VMD h/w irqs. The VMD driver then has to de-mux that into
CPU side irqs for each device.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1215645

FromJiang Liu <jiang.liu@linux.intel.com>
Date2015-08-29 03:50 +0200
Message-ID<q2Drj-44B-9@gated-at.bofh.it>
In reply to#1215447
On 2015/8/29 0:54, Thomas Gleixner wrote:
> On Thu, 27 Aug 2015, Keith Busch wrote:
> 
>> This patch adds struct x86_msi_ops to x86's PCI sysdata. This gives a
>> host bridge driver the option to provide alternate MSI Data Register
>> and MSI-X Table Entry programming for devices in PCI domains that do
>> not subscribe to usual "IOAPIC" format.
> 
> I'm not too fond about more ad hoc indirection and special casing. We
> should be able to handle this with hierarchical irq domains. Jiang
> might have an idea how to do that for your case.
Hi Thomas and Keith,
	I have noticed this patch set yesterday, but still investigating the
better way to handle this. Basically I think
we should build per-domain/per-bus/per-device PCI MSI irqdomain,
just like what ARM have done. That will give us a clear picture.
But I need more information about the hardware topology
to correctly build up the hierarchical irqdomain, especially the
relationship between the embedded host bridge and IOMMU units.
	Keith, could you please help to provide some doc with
hardware details?
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web