MSI support for Marvell EBU PCIe driver
Subsystems (14)
v4 cover MSI support for Marvell EBU PCIe driver
Hello,
This set of patches introduces Message Signaled Interrupt support in the Marvell EBU PCIe driver. It has been successfully tested on the Armada XP GP platform with an Intel e1000e PCIe network card that supports MSI.
The patches do the following:
* Patch 1 adds an IRQ domain function that allows to allocate dynamically a free hwirq number from an IRQ domain, and create a virq mapping to it. It was suggested by Grant Likely in order to remove the hwirq allocation code from the IRQ driver itself.
This patch needs the Ack of Grant Likely.
* Patch 2 reworks how the architecture-specific MSI functions can be overriden by architecture-specific code, by using weak functions. It was suggested by Bjorn Helgaas.
This patch needs the Ack from Bjorn Helgaas, and the relevant architecture maintainers.
* Patch 3 removes the ARCH_SUPPORTS_MSI hidden kconfig boolean which is no longer needed now that we have weak functions for all MSI architecture-specific hooks.
This patch needs the Ack from Bjorn Helgaas, and the relevant architecture maintainers.
* Patch 4 adds a minimal msi_chip infrastructure, that allows a pci_bus to be connected to a msi_chip, and that provides default implementations of the architecture-specific MSI functions to use msi_chip.
This patch needs the Ack from Bjorn Helgaas.
* Patch 5 adds a small registry of msi_chip <-> of_node in the OF code. It was originally located in drivers/pci/msi.c, but Bjorn Helgaas suggested that it probably belongs to drivers/of/.
This patch needs the Ack from Grant Likely or Rob Herring, and probably Bjorn Helgaas as well.
* Patch 6 makes some not very interesting preparation in the Armada 370/XP IRQ controller driver.
This patch needs the Ack from Thomas Gleixner.
* Patch 7 implements the MSI support in the Armada 370/XP IRQ controller driver. It registers an msi_chip using the msi_chip_add() function added in PATCH 3.
This patch needs the Ack from Thomas Gleixner.
* Patch 8 extends the ARM PCI core to expose ->add_bus() and ->remove_bus() hooks to PCI drivers. This was suggested by Bjorn Helgaas to allow the PCI driver to connected the PCI busses with the corresponding MSI chip.
This patch needs the Ack from Russell King.
* Patch 9 adjust the Armada 370/XP Device Tree to indicate that the MPIC is not only an interrupt-controller, but also an msi-controller.
This patch needs the Ack from Jason Cooper, Gregory Clement and/or Andrew Lunn, the Marvell Maintainers.
* Patch 10 adds MSI support in the Marvell PCIe host controller driver. The work to do here is minimal: get a reference to the msi-parent controller thanks to msi_chip_find_by_of_node(), and link it to the pci_bus structure before the bus gets enumerated.
This patch needs the Ack from Bjorn Helgaas.
* Patch 11 adjusts the Armada 370/XP Device Tree to add the msi-parent properties in the PCIe controller nodes.
This patch needs the Ack from Jason Cooper, Gregory Clement and/or Andrew Lunn, the Marvell Maintainers.
This version 4 follows:
* PATCH version 3 sent on June, 19th 2013
* PATCH version 2 sent on June, 6th 2013
* RFC version 1 sent on March, 26th 2013
Changes since v3:
* Keep only a default_teardown_msi_irqs() function needed for the Xen PCI x86 code, and remove all other default_*() function and put the default behavior directly in the weak functions. Suggested by Thierry Redding and Bjorn Helgaas.
* Misc small improvements the MSI chip registry code: compiled only under CONFIG_PCI_MSI, functions exported to modules, addition of an of_msi_chip_remove() function, renaming of of_msi_chip_find_by_node() to of_find_msi_chip_by_node(), move the test of the "msi-controller" property to the of_msi_chip_add() function, renamed the list_head field from link to list, added dummy functions in the header files when !CONFIG_PCI_MSI && !CONFIG_OF. All suggested by Thierry Redding.
* Add a patch that entirely removes the ARCH_SUPPORTS_MSI, as we now have weak functions, so even if an arch doesn't actually use/support MSI, the code will build properly. Suggested by Thierry Redding.
* Added Device Tree binding documentation updates for the IRQ controller and the PCIe controller.
Changes since v2:
* Add an IRQ domain function that allows to allocate dynamically a free hwirq number from an IRQ domain, and create a virq mapping to it. It was suggested by Grant Likely in order to remove the hwirq allocation code from the IRQ driver itself. (PATCH 1)
* Separate the use of weak functions from the introduction of the msi_chip infrastructure, and use weak functions for all architecture-specific MSI hooks. Suggested by Bjorn Helgaas (PATCH 2).
* Move the msi_chip registry to drivers/of. Suggested by Bjorn Helgaas (PATCH 4).
* Use pcibios_add_bus() and pcibios_remove_bus() to connect the PCI busses to their msi_chip, as suggested by Bjorn Helgaas. Requires some ARM PCI core changes (PATCH 7), and then changes to the PCI driver itself (PATCH 9).
This set of patches currently applies on top of the current "for-next" branch of Jason Cooper's repository + the irqdomain/test branch of Grant Likely's tree. I will rebase them on top of 3.11-rc1 when it lands, but I'd like to start collecting Acked-by from maintainers in the mean time.
Thanks,
Thomas
Thierry Reding (1):
PCI: Introduce new MSI chip infrastructure
Thomas Petazzoni (10):
irqdomain: add irq_alloc_mapping() function
pci: use weak functions for MSI arch-specific functions
pci: remove ARCH_SUPPORTS_MSI kconfig option
of: pci: add registry of MSI chips
irqchip: armada-370-xp: properly request resources
irqchip: armada-370-xp: implement MSI support
arm: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci
arm: mvebu: the MPIC now provides MSI controller features
pci: mvebu: add support for MSI
arm: mvebu: link PCIe controllers to the MSI controller
.../devicetree/bindings/arm/armada-370-xp-mpic.txt | 3 + .../devicetree/bindings/pci/mvebu-pci.txt | 3 + arch/arm/Kconfig | 1 - arch/arm/boot/dts/armada-370-xp.dtsi | 1 + arch/arm/boot/dts/armada-370.dtsi | 1 + arch/arm/boot/dts/armada-xp-mv78230.dtsi | 1 + arch/arm/boot/dts/armada-xp-mv78260.dtsi | 1 + arch/arm/boot/dts/armada-xp-mv78460.dtsi | 1 + arch/arm/include/asm/mach/pci.h | 4 + arch/arm/kernel/bios32.c | 16 ++ arch/ia64/Kconfig | 1 - arch/mips/Kconfig | 2 - arch/mips/include/asm/pci.h | 5 - arch/powerpc/Kconfig | 1 - arch/powerpc/include/asm/pci.h | 5 - arch/s390/Kconfig | 1 - arch/s390/include/asm/pci.h | 4 - arch/sparc/Kconfig | 1 - arch/tile/Kconfig | 1 - arch/x86/Kconfig | 1 - arch/x86/include/asm/pci.h | 28 ---- arch/x86/kernel/x86_init.c | 21 +++ drivers/irqchip/irq-armada-370-xp.c | 161 ++++++++++++++++++++- drivers/of/of_pci.c | 40 +++++ drivers/pci/Kconfig | 4 - drivers/pci/host/pci-mvebu.c | 26 ++++ drivers/pci/msi.c | 67 +++++---- drivers/pci/probe.c | 1 + include/linux/irqdomain.h | 2 + include/linux/msi.h | 20 ++- include/linux/of_pci.h | 12 ++ include/linux/pci.h | 1 + kernel/irq/irqdomain.c | 32 ++++ 33 files changed, 383 insertions(+), 86 deletions(-)
Signature · 1 line
1.8.1.2
PATCH v4 1/11 irqdomain: add irq_alloc_mapping() function
This commit extends the irqdomain subsystem with an irq_alloc_mapping() function which allows to let the irqdomain code find an available hwirq number in the range [ 0 ; domain size ] for the given domain, and create a virq mapping for it.
--- include/linux/irqdomain.h | 2 ++ kernel/irq/irqdomain.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+)
include/linux/irqdomain.h +2 -0
@@ -195,6 +195,8 @@ static inline unsigned int irq_linear_revmap(struct irq_domain *domain,extern unsigned int irq_find_mapping (struct irq_domain *host,irq_hw_number_t hwirq);extern unsigned int irq_create_direct_mapping (struct irq_domain *host); +extern unsigned int irq_alloc_mapping (struct irq_domain *host, +irq_hw_number_t *hwirq);extern int irq_create_strict_mappings (struct irq_domain *domain,unsigned int irq_base,irq_hw_number_t hwirq_base,int count);
kernel/irq/irqdomain.c +32 -0
@@ -375,6 +375,38 @@ unsigned int irq_create_direct_mapping(struct irq_domain *domain)EXPORT_SYMBOL_GPL (irq_create_direct_mapping);/** +* irq_alloc_mapping() - Allocate an irq for mapping +* @domain: domain to allocate the irq for or NULL for default domain +* @hwirq: reference to the returned hwirq +* +* This routine are used for irq controllers which can choose the +* hardware interrupt number from a range [ 0 ; domain size ], such as +* is often the case with PCI MSI controllers. The function will +* returned the allocated hwirq number in the hwirq pointer, and the +* corresponding virq number as the return value. +*/ +unsigned int irq_alloc_mapping (struct irq_domain *domain, +irq_hw_number_t *out_hwirq) +{ +irq_hw_number_t hwirq; + +pr_debug ("irq_alloc_mapping(0x%p)\n" , domain); + +for (hwirq =0 ; hwirq < domain->hwirq_max; hwirq++) +if (!irq_find_mapping (domain, hwirq)) +break ; + +if (hwirq == domain->hwirq_max) { +pr_debug ("-> no available hwirq found\n" ); +return 0 ; + } + + *out_hwirq = hwirq; +return irq_create_mapping (domain, hwirq); +} +EXPORT_SYMBOL_GPL (irq_alloc_mapping); + +/** * irq_create_mapping() - Map a hardware interrupt into linux irq space * @domain: domain owning this hardware interrupt or NULL for default domain * @hwirq: hardware irq number in that domain space
Signature · 1 line
1.8.1.2
PATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
In reply to Thomas PetazzoniUntil now, the MSI architecture-specific functions could be overloaded using a fairly complex set of #define and compile-time conditionals. In order to prepare for the introduction of the msi_chip infrastructure, it is desirable to switch all those functions to use the 'weak' mechanism. This commit converts all the architectures that were overidding those MSI functions to use the new strategy.
Note that we keep a separate, non-weak, function default_teardown_msi_irqs() for the default behavior of the arch_teardown_msi_irqs(), as the default behavior is needed by the Xen x86 PCI code.
--- arch/mips/include/asm/pci.h | 5 ----- arch/powerpc/include/asm/pci.h | 5 ----- arch/s390/include/asm/pci.h | 4 ---- arch/x86/include/asm/pci.h | 28 -------------------------- arch/x86/kernel/x86_init.c | 21 ++++++++++++++++++++ drivers/pci/msi.c | 45 +++++++++++++++++++----------------------- include/linux/msi.h | 7 ++++++- 7 files changed, 47 insertions(+), 68 deletions(-)
arch/mips/include/asm/pci.h +0 -5
@@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)return channel ?15 :14 ; } -#ifdef CONFIG_CPU_CAVIUM_OCTEON -/* MSI arch hook for OCTEON */ -#define arch_setup_msi_irqs arch_setup_msi_irqs -#endif -extern char * (*pcibios_plat_setup)(char *str);#ifdef CONFIG_OF
arch/powerpc/include/asm/pci.h +0 -5
@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);/* Decide whether to display the domain number in /proc */ extern int pci_proc_domain (struct pci_bus *bus); -/* MSI arch hooks */ -#define arch_setup_msi_irqs arch_setup_msi_irqs -#define arch_teardown_msi_irqs arch_teardown_msi_irqs -#define arch_msi_check_device arch_msi_check_device -struct vm_area_struct ;/* Map a range of PCI memory or I/O space for a device into user space */ int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
arch/s390/include/asm/pci.h +0 -4
@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);int pci_domain_nr (struct pci_bus *);int pci_proc_domain (struct pci_bus *); -/* MSI arch hooks */ -#define arch_setup_msi_irqs arch_setup_msi_irqs -#define arch_teardown_msi_irqs arch_teardown_msi_irqs -#define ZPCI_BUS_NR 0/* default bus number */ #define ZPCI_DEVFN 0/* default device number */
arch/x86/include/asm/pci.h +0 -28
@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }extern void pci_iommu_alloc (void );#ifdef CONFIG_PCI_MSI -/* MSI arch specific hooks */ -static inline int x86_setup_msi_irqs (struct pci_dev *dev,int nvec,int type) -{ -return x86_msi.setup_msi_irqs (dev, nvec, type); -} - -static inline void x86_teardown_msi_irqs (struct pci_dev *dev) -{ - x86_msi.teardown_msi_irqs (dev); -} - -static inline void x86_teardown_msi_irq (unsigned int irq) -{ - x86_msi.teardown_msi_irq (irq); -} -static inline void x86_restore_msi_irqs (struct pci_dev *dev,int irq) -{ - x86_msi.restore_msi_irqs (dev, irq); -} -#define arch_setup_msi_irqs x86_setup_msi_irqs -#define arch_teardown_msi_irqs x86_teardown_msi_irqs -#define arch_teardown_msi_irq x86_teardown_msi_irq -#define arch_restore_msi_irqs x86_restore_msi_irqs/* implemented in arch/x86/kernel/apic/io_apic. */ struct msi_desc ;int native_setup_msi_irqs (struct pci_dev *dev,int nvec,int type);
@@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);void native_restore_msi_irqs (struct pci_dev *dev,int irq);int setup_msi_irq (struct pci_dev *dev,struct msi_desc *msidesc,unsigned int irq_base,unsigned int irq_offset); -/* default to the implementation in drivers/lib/msi.c */ -#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS -#define HAVE_DEFAULT_MSI_RESTORE_IRQS -void default_teardown_msi_irqs (struct pci_dev *dev); -void default_restore_msi_irqs (struct pci_dev *dev,int irq);#else #define native_setup_msi_irqs NULL#define native_teardown_msi_irq NULL
arch/x86/kernel/x86_init.c +21 -0
@@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = { .setup_hpet_msi = default_setup_hpet_msi, }; +/* MSI arch specific hooks */ +int arch_setup_msi_irqs (struct pci_dev *dev,int nvec,int type) +{ +return x86_msi.setup_msi_irqs (dev, nvec, type); +} + +void arch_teardown_msi_irqs (struct pci_dev *dev) +{ + x86_msi.teardown_msi_irqs (dev); +} + +void arch_teardown_msi_irq (unsigned int irq) +{ + x86_msi.teardown_msi_irq (irq); +} + +void arch_restore_msi_irqs (struct pci_dev *dev,int irq) +{ + x86_msi.restore_msi_irqs (dev, irq); +} +struct x86_io_apic_ops x86_io_apic_ops = { .init = native_io_apic_init_mappings, .read = native_io_apic_read,
drivers/pci/msi.c +20 -25
76 lines not on this page · raw message
include/linux/msi.h +6 -1
@@ -50,12 +50,17 @@ struct msi_desc { };/* -* The arch hook for setup up msi irqs +* The arch hooks to setup up msi irqs. Those functions are +* implemented as weak symbols so that they /can/ be overriden by +* architecture specific code if needed. */ int arch_setup_msi_irq (struct pci_dev *dev,struct msi_desc *desc);void arch_teardown_msi_irq (unsigned int irq);int arch_setup_msi_irqs (struct pci_dev *dev,int nvec,int type);void arch_teardown_msi_irqs (struct pci_dev *dev);int arch_msi_check_device (struct pci_dev * dev,int nvec,int type); +void arch_restore_msi_irqs (struct pci_dev *dev,int irq); + +void default_teardown_msi_irqs (struct pci_dev *dev);#endif /* LINUX_MSI_H */
Signature · 1 line
1.8.1.2
PATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
Quoted 6 lines · Thomas Petazzoni
Until now, the MSI architecture-specific functions could be overloaded using a fairly complex set of #define and compile-time conditionals. In order to prepare for the introduction of the
msi_chipinfrastructure, it is desirable to switch all those functions to use the 'weak' mechanism. This commit converts all the architectures that were overidding those MSI functions to use the new strategy.
The MSI code used to use weak functions, until we discovered they were being miscompiled on some toolchains (11df1f0). I assume these days we're confident they work correctly.
cheers
PATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
Dear Michael Ellerman,
Quoted 11 lines · Michael Ellerman
Quoted 6 lines · Thomas Petazzoni
Until now, the MSI architecture-specific functions could be overloaded using a fairly complex set of #define and compile-time conditionals. In order to prepare for the introduction of the
msi_chipinfrastructure, it is desirable to switch all those functions to use the 'weak' mechanism. This commit converts all the architectures that were overidding those MSI functions to use the new strategy.The MSI code used to use weak functions, until we discovered they were being miscompiled on some toolchains (11df1f0). I assume these days we're confident they work correctly.
Hum, interesting. I see from your commit that gcc 4.3.2 was apparently affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of view on this?
Another option would be to have architecture register some msi_arch_ops structure, with a set of operations, which I believe is a pattern that is more widespread in the kernel than weak functions.
Thoughts?
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
Quoted 11 lines · Thomas Petazzoni
Dear Michael Ellerman,
Quoted 8 lines · Michael Ellerman
Quoted 6 lines · Thomas Petazzoni
Until now, the MSI architecture-specific functions could be overloaded using a fairly complex set of #define and compile-time conditionals. In order to prepare for the introduction of the
msi_chipinfrastructure, it is desirable to switch all those functions to use the 'weak' mechanism. This commit converts all the architectures that were overidding those MSI functions to use the new strategy.
Quoted 7 lines
Quoted 3 lines
The MSI code used to use weak functions, until we discovered they were being miscompiled on some toolchains (11df1f0). I assume these days we're confident they work correctly.
Hum, interesting. I see from your commit that gcc 4.3.2 was apparently affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of view on this?
Stop press.
I went back and found the old threads on this, it's been a while. It looks like it was only gcc 4.1.[01] that miscompiled. The reference to gcc 4.3.2 was WRT ellision of the unused code, which is a separate issue.
The kernel blacklists gcc 4.1.[01] (see f9d1425), so weak should be safe to use.
We merged the change to the PCI code anyway because we thought it was nicer and it also avoided any problems with weak.
So pretend I never said anything :)
cheers
Bjorn Helgaas
maintainerPATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
In reply to Thomas PetazzoniQuoted 11 lines · Thomas Petazzoni
Dear Michael Ellerman,
Quoted 8 lines · Michael Ellerman
Quoted 6 lines · Thomas Petazzoni
Until now, the MSI architecture-specific functions could be overloaded using a fairly complex set of #define and compile-time conditionals. In order to prepare for the introduction of the
msi_chipinfrastructure, it is desirable to switch all those functions to use the 'weak' mechanism. This commit converts all the architectures that were overidding those MSI functions to use the new strategy.
Quoted 7 lines
Quoted 3 lines
The MSI code used to use weak functions, until we discovered they were being miscompiled on some toolchains (11df1f0). I assume these days we're confident they work correctly.
Hum, interesting. I see from your commit that gcc 4.3.2 was apparently affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of view on this?
There *were* compilation issues with weak functions, but AFAIK they've been resolved and there's no reason to avoid them. Commit f9d142500 addressed this.
Bjorn
Bjorn Helgaas
maintainerPATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
In reply to Thomas PetazzoniQuoted 25 lines · Thomas Petazzoni
Until now, the MSI architecture-specific functions could be overloaded using a fairly complex set of #define and compile-time conditionals. In order to prepare for the introduction of the
msi_chipinfrastructure, it is desirable to switch all those functions to use the 'weak' mechanism. This commit converts all the architectures that were overidding those MSI functions to use the new strategy.Note that we keep a separate, non-weak, function
default_teardown_msi_irqs()for the default behavior of thearch_teardown_msi_irqs(), as the default behavior is needed by the Xen x86 PCI code.Signed-off-by Thomas Petazzoni <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc linuxppc-dev at lists.ozlabs.orgCc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Cc linux390 at de.ibm.comCc linux-s390 at vger.kernel.orgCc Thomas Gleixner <[email protected]>Cc Ingo Molnar <[email protected]>Cc H. Peter Anvin <[email protected]>Cc x86 at kernel.orgCc Russell King <[email protected]>
Quoted 8 lines
Cc Tony Luck <[email protected]>Cc Fenghua Yu <[email protected]>Cc linux-ia64 at vger.kernel.orgCc Ralf Baechle <[email protected]>Cc linux-mips at linux-mips.orgCc David S. Miller <[email protected]>Cc sparclinux at vger.kernel.orgCc Chris Metcalf <[email protected]>
Quoted 245 lines
--- arch/mips/include/asm/pci.h | 5 ----- arch/powerpc/include/asm/pci.h | 5 ----- arch/s390/include/asm/pci.h | 4 ---- arch/x86/include/asm/pci.h | 28 -------------------------- arch/x86/kernel/x86_init.c | 21 ++++++++++++++++++++ drivers/pci/msi.c | 45 +++++++++++++++++++----------------------- include/linux/msi.h | 7 ++++++- 7 files changed, 47 insertions(+), 68 deletions(-)arch/mips/include/asm/pci.h +0
-5@@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)return channel ?15 :14 ; } -#ifdef CONFIG_CPU_CAVIUM_OCTEON -/* MSI arch hook for OCTEON */ -#define arch_setup_msi_irqs arch_setup_msi_irqs -#endif -extern char * (*pcibios_plat_setup)(char *str);#ifdef CONFIG_OF arch/powerpc/include/asm/pci.h +0
-5@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);/* Decide whether to display the domain number in /proc */ extern int pci_proc_domain (struct pci_bus *bus); -/* MSI arch hooks */ -#define arch_setup_msi_irqs arch_setup_msi_irqs -#define arch_teardown_msi_irqs arch_teardown_msi_irqs -#define arch_msi_check_device arch_msi_check_device -struct vm_area_struct ;/* Map a range of PCI memory or I/O space for a device into user space */ int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,arch/s390/include/asm/pci.h +0
-4@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);int pci_domain_nr (struct pci_bus *);int pci_proc_domain (struct pci_bus *); -/* MSI arch hooks */ -#define arch_setup_msi_irqs arch_setup_msi_irqs -#define arch_teardown_msi_irqs arch_teardown_msi_irqs -#define ZPCI_BUS_NR 0/* default bus number */ #define ZPCI_DEVFN 0/* default device number */ arch/x86/include/asm/pci.h +0
-28@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }extern void pci_iommu_alloc (void );#ifdef CONFIG_PCI_MSI -/* MSI arch specific hooks */ -static inline int x86_setup_msi_irqs (struct pci_dev *dev,int nvec,int type) -{ -return x86_msi.setup_msi_irqs (dev, nvec, type); -} - -static inline void x86_teardown_msi_irqs (struct pci_dev *dev) -{ - x86_msi.teardown_msi_irqs (dev); -} - -static inline void x86_teardown_msi_irq (unsigned int irq) -{ - x86_msi.teardown_msi_irq (irq); -} -static inline void x86_restore_msi_irqs (struct pci_dev *dev,int irq) -{ - x86_msi.restore_msi_irqs (dev, irq); -} -#define arch_setup_msi_irqs x86_setup_msi_irqs -#define arch_teardown_msi_irqs x86_teardown_msi_irqs -#define arch_teardown_msi_irq x86_teardown_msi_irq -#define arch_restore_msi_irqs x86_restore_msi_irqs/* implemented in arch/x86/kernel/apic/io_apic. */ struct msi_desc ;int native_setup_msi_irqs (struct pci_dev *dev,int nvec,int type);@@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);void native_restore_msi_irqs (struct pci_dev *dev,int irq);int setup_msi_irq (struct pci_dev *dev,struct msi_desc *msidesc,unsigned int irq_base,unsigned int irq_offset); -/* default to the implementation in drivers/lib/msi.c */ -#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS -#define HAVE_DEFAULT_MSI_RESTORE_IRQS -void default_teardown_msi_irqs (struct pci_dev *dev); -void default_restore_msi_irqs (struct pci_dev *dev,int irq);#else #define native_setup_msi_irqs NULL#define native_teardown_msi_irq NULLarch/x86/kernel/x86_init.c +21
-0@@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = { .setup_hpet_msi = default_setup_hpet_msi, }; +/* MSI arch specific hooks */ +int arch_setup_msi_irqs (struct pci_dev *dev,int nvec,int type) +{ +return x86_msi.setup_msi_irqs (dev, nvec, type); +} + +void arch_teardown_msi_irqs (struct pci_dev *dev) +{ + x86_msi.teardown_msi_irqs (dev); +} + +void arch_teardown_msi_irq (unsigned int irq) +{ + x86_msi.teardown_msi_irq (irq); +} + +void arch_restore_msi_irqs (struct pci_dev *dev,int irq) +{ + x86_msi.restore_msi_irqs (dev, irq); +} +struct x86_io_apic_ops x86_io_apic_ops = { .init = native_io_apic_init_mappings, .read = native_io_apic_read,drivers/pci/msi.c +20
-25@@ -30,20 +30,21 @@ static int pci_msi_enable = 1;/* Arch hooks */ -#ifndef arch_msi_check_device -int arch_msi_check_device (struct pci_dev *dev,int nvec,int type) +int __weak arch_setup_msi_irq (struct pci_dev *dev,struct msi_desc *desc) { -return 0 ; +return -EINVAL ; } -#endif -#ifndef arch_setup_msi_irqs -# define arch_setup_msi_irqs default_setup_msi_irqs -# define HAVE_DEFAULT_MSI_SETUP_IRQS -#endif +void __weak arch_teardown_msi_irq (unsigned int irq) +{ +} -#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS -int default_setup_msi_irqs (struct pci_dev *dev,int nvec,int type) +int __weak arch_msi_check_device (struct pci_dev *dev,int nvec,int type) +{ +return 0 ; +} + +int __weak arch_setup_msi_irqs (struct pci_dev *dev,int nvec,int type) {struct msi_desc *entry;int ret;@@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)return 0 ; } -#endif -#ifndef arch_teardown_msi_irqs -# define arch_teardown_msi_irqs default_teardown_msi_irqs -# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS -#endif - -#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS +/* +* We have a default implementation available as a separate non-weak +* function, as it is used by the Xen x86 PCI code +*/ void default_teardown_msi_irqs (struct pci_dev *dev) {struct msi_desc *entry;@@ -86,15 +84,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)arch_teardown_msi_irq (entry->irq + i); } } -#endif -#ifndef arch_restore_msi_irqs -# define arch_restore_msi_irqs default_restore_msi_irqs -# define HAVE_DEFAULT_MSI_RESTORE_IRQS -#endif +void __weak arch_teardown_msi_irqs (struct pci_dev *dev) +{ +return default_teardown_msi_irqs (dev); +} -#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS -void default_restore_msi_irqs (struct pci_dev *dev,int irq) +void __weak arch_restore_msi_irqs (struct pci_dev *dev,int irq) {struct msi_desc *entry;@@ -111,7 +107,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)if (entry)write_msi_msg (irq, &entry->msg); } -#endif static void msi_set_enable (struct pci_dev *dev,int enable) {include/linux/msi.h +6
-2@@ -50,12 +50,17 @@ struct msi_desc { };/* -* The arch hook for setup up msi irqs +* The arch hooks to setup up msi irqs. Those functions are +* implemented as weak symbols so that they /can/ be overriden by +* architecture specific code if needed. */ int arch_setup_msi_irq (struct pci_dev *dev,struct msi_desc *desc);void arch_teardown_msi_irq (unsigned int irq);int arch_setup_msi_irqs (struct pci_dev *dev,int nvec,int type);void arch_teardown_msi_irqs (struct pci_dev *dev);int arch_msi_check_device (struct pci_dev * dev,int nvec,int type); +void arch_restore_msi_irqs (struct pci_dev *dev,int irq); + +void default_teardown_msi_irqs (struct pci_dev *dev);#endif /* LINUX_MSI_H */ --1.8.1.2
Bjorn Helgaas
maintainerPATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
Quoted 1 line · Bjorn Helgaas
Acked-by Bjorn Helgaas <[email protected]>
But please update your subject line to use consistent capitalization, e.g.,
PCI: Use weak ...
PATCH v4 2/11 pci: use weak functions for MSI arch-specific functions
Dear Bjorn Helgaas,
Quoted 7 lines · Bjorn Helgaas
Quoted 1 line · Bjorn Helgaas
Acked-by Bjorn Helgaas <[email protected]>But please update your subject line to use consistent capitalization, e.g.,
PCI: Use weak ...
Sure, will do.
Would it be possible to get Tested-by and/or Acked-by from the different architecture maintainers affected by PATCH 02/11 and PATCH 03/11 ?
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 3/11 pci: remove ARCH_SUPPORTS_MSI kconfig option
In reply to Thomas PetazzoniNow that we have weak versions for each of the PCI MSI architecture functions, we can actually build the MSI support for all platforms, regardless of whether they provide or not architecture-specific versions of those functions. For this reason, the ARCH_SUPPORTS_MSI hidden kconfig boolean becomes useless, and this patch gets rid of it.
--- arch/arm/Kconfig | 1 - arch/ia64/Kconfig | 1 - arch/mips/Kconfig | 2 -- arch/powerpc/Kconfig | 1 - arch/s390/Kconfig | 1 - arch/sparc/Kconfig | 1 - arch/tile/Kconfig | 1 - arch/x86/Kconfig | 1 - drivers/pci/Kconfig | 4 ---- 9 files changed, 13 deletions(-)
arch/arm/Kconfig +0 -1
@@ -435,7 +435,6 @@ config ARCH_NETX config ARCH_IOP13XX bool "IOP13xx-based" depends on MMU - select ARCH_SUPPORTS_MSI select CPU_XSC3 select NEED_MACH_MEMORY_H select NEED_RET_TO_USER
arch/ia64/Kconfig +0 -1
@@ -9,7 +9,6 @@ config IA64 select PCI if (!IA64_HP_SIM) select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) - select ARCH_SUPPORTS_MSI select HAVE_UNSTABLE_SCHED_CLOCK select HAVE_IDE select HAVE_OPROFILE
arch/mips/Kconfig +0 -2
@@ -763,7 +763,6 @@ config CAVIUM_OCTEON_REFERENCE_BOARD select SYS_HAS_CPU_CAVIUM_OCTEON select SWAP_IO_SPACE select HW_HAS_PCI - select ARCH_SUPPORTS_MSI select ZONE_DMA32 select USB_ARCH_HAS_OHCI select USB_ARCH_HAS_EHCI
@@ -799,7 +798,6 @@ config NLM_XLR_BOARD select CEVT_R4K select CSRC_R4K select IRQ_CPU - select ARCH_SUPPORTS_MSI select ZONE_DMA32 if 64BIT select SYNC_R4K select SYS_HAS_EARLY_PRINTK
arch/powerpc/Kconfig +0 -1
@@ -734,7 +734,6 @@ config PCI default y if !40x && !CPM2 && !8xx && !PPC_83xx \ && !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON default PCI_QSPAN if !4xx && !CPM2 && 8xx - select ARCH_SUPPORTS_MSI select GENERIC_PCI_IOMAP help Find out whether your system includes a PCI bus. PCI is the name of
arch/s390/Kconfig +0 -1
@@ -429,7 +429,6 @@ menuconfig PCI bool "PCI support" default n depends on 64BIT - select ARCH_SUPPORTS_MSI select PCI_MSI help Enable PCI support.
arch/sparc/Kconfig +0 -1
@@ -52,7 +52,6 @@ config SPARC32 config SPARC64 def_bool 64BIT - select ARCH_SUPPORTS_MSI select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_GRAPH_FP_TEST
arch/tile/Kconfig +0 -1
@@ -379,7 +379,6 @@ config PCI select PCI_DOMAINS select GENERIC_PCI_IOMAP select TILE_GXIO_TRIO if TILEGX - select ARCH_SUPPORTS_MSI if TILEGX select PCI_MSI if TILEGX ---help--- Enable PCI root complex support, so PCIe endpoint devices can
arch/x86/Kconfig +0 -1
@@ -1999,7 +1999,6 @@ menu "Bus options (PCI etc.)" config PCI bool "PCI support" default y - select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC) ---help--- Find out whether you have a PCI motherboard. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff inside
drivers/pci/Kconfig +0 -4
@@ -1,13 +1,9 @@ # # PCI configuration # -config ARCH_SUPPORTS_MSI - bool - config PCI_MSI bool "Message Signaled Interrupts (MSI and MSI-X)" depends on PCI - depends on ARCH_SUPPORTS_MSI help This allows device drivers to enable MSI (Message Signaled Interrupts). Message Signaled Interrupts enable a device to
Signature · 1 line
1.8.1.2
Bjorn Helgaas
maintainerPATCH v4 3/11 pci: remove ARCH_SUPPORTS_MSI kconfig option
Quoted 19 lines · Thomas Petazzoni
Now that we have weak versions for each of the PCI MSI architecture functions, we can actually build the MSI support for all platforms, regardless of whether they provide or not architecture-specific versions of those functions. For this reason, the
ARCH_SUPPORTS_MSIhidden kconfig boolean becomes useless, and this patch gets rid of it.Signed-off-by Thomas Petazzoni <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc linuxppc-dev at lists.ozlabs.orgCc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Cc linux390 at de.ibm.comCc linux-s390 at vger.kernel.orgCc Thomas Gleixner <[email protected]>Cc Ingo Molnar <[email protected]>Cc H. Peter Anvin <[email protected]>Cc x86 at kernel.orgCc Russell King <[email protected]>
Quoted 8 lines
Cc Tony Luck <[email protected]>Cc Fenghua Yu <[email protected]>Cc linux-ia64 at vger.kernel.orgCc Ralf Baechle <[email protected]>Cc linux-mips at linux-mips.orgCc David S. Miller <[email protected]>Cc sparclinux at vger.kernel.orgCc Chris Metcalf <[email protected]>
Again, please update the subject line to "PCI: Remove ..."
I doubt that you'll get explicit acks from all the arches you touched, but I think it's reasonable to put at least patches 2 & 3 in -next soon after v3.11-rc1, so we should have time to shake out issues.
Quoted 137 lines
--- arch/arm/Kconfig | 1 - arch/ia64/Kconfig | 1 - arch/mips/Kconfig | 2 -- arch/powerpc/Kconfig | 1 - arch/s390/Kconfig | 1 - arch/sparc/Kconfig | 1 - arch/tile/Kconfig | 1 - arch/x86/Kconfig | 1 - drivers/pci/Kconfig | 4 ---- 9 files changed, 13 deletions(-)arch/arm/Kconfig +0
-1@@ -435,7 +435,6 @@ config ARCH_NETX config ARCH_IOP13XX bool "IOP13xx-based" depends on MMU - select ARCH_SUPPORTS_MSI select CPU_XSC3 select NEED_MACH_MEMORY_H select NEED_RET_TO_USERarch/ia64/Kconfig +0
-1@@ -9,7 +9,6 @@ config IA64 select PCI if (!IA64_HP_SIM) select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) - select ARCH_SUPPORTS_MSI select HAVE_UNSTABLE_SCHED_CLOCK select HAVE_IDE select HAVE_OPROFILEarch/mips/Kconfig +0
-2@@ -763,7 +763,6 @@ config CAVIUM_OCTEON_REFERENCE_BOARD select SYS_HAS_CPU_CAVIUM_OCTEON select SWAP_IO_SPACE select HW_HAS_PCI - select ARCH_SUPPORTS_MSI select ZONE_DMA32 select USB_ARCH_HAS_OHCI select USB_ARCH_HAS_EHCI@@ -799,7 +798,6 @@ config NLM_XLR_BOARD select CEVT_R4K select CSRC_R4K select IRQ_CPU - select ARCH_SUPPORTS_MSI select ZONE_DMA32 if 64BIT select SYNC_R4K select SYS_HAS_EARLY_PRINTKarch/powerpc/Kconfig +0
-1@@ -734,7 +734,6 @@ config PCI default y if !40x && !CPM2 && !8xx && !PPC_83xx \ && !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON default PCI_QSPAN if !4xx && !CPM2 && 8xx - select ARCH_SUPPORTS_MSI select GENERIC_PCI_IOMAP help Find out whether your system includes a PCI bus. PCI is the name ofarch/s390/Kconfig +0
-1@@ -429,7 +429,6 @@ menuconfig PCI bool "PCI support" default n depends on 64BIT - select ARCH_SUPPORTS_MSI select PCI_MSI help Enable PCI support.arch/sparc/Kconfig +0
-1@@ -52,7 +52,6 @@ config SPARC32 config SPARC64 def_bool 64BIT - select ARCH_SUPPORTS_MSI select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_GRAPH_FP_TESTarch/tile/Kconfig +0
-1@@ -379,7 +379,6 @@ config PCI select PCI_DOMAINS select GENERIC_PCI_IOMAP select TILE_GXIO_TRIO if TILEGX - select ARCH_SUPPORTS_MSI if TILEGX select PCI_MSI if TILEGX ---help--- Enable PCI root complex support, so PCIe endpoint devices canarch/x86/Kconfig +0
-1@@ -1999,7 +1999,6 @@ menu "Bus options (PCI etc.)" config PCI bool "PCI support" default y - select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC) ---help--- Find out whether you have a PCI motherboard. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff insidedrivers/pci/Kconfig +0
-5@@ -1,13 +1,9 @@ # # PCI configuration # -config ARCH_SUPPORTS_MSI - bool - config PCI_MSI bool "Message Signaled Interrupts (MSI and MSI-X)" depends on PCI - depends on ARCH_SUPPORTS_MSI help This allows device drivers to enable MSI (Message Signaled Interrupts). Message Signaled Interrupts enable a device to --1.8.1.2
PATCH v4 3/11 pci: remove ARCH_SUPPORTS_MSI kconfig option
Dear Bjorn Helgaas,
Quoted 7 lines · Bjorn Helgaas
Acked-by Bjorn Helgaas <[email protected]>Again, please update the subject line to "PCI: Remove ..."
I doubt that you'll get explicit acks from all the arches you touched, but I think it's reasonable to put at least patches 2 & 3 in -next soon after v3.11-rc1, so we should have time to shake out issues.
Sure. Which merge strategy do you suggest for this patch series, which touches a number of different areas, and has some build-time dependencies between the patches (if needed, I can detail those build time dependencies to help figuring out the best strategy).
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 3/11 pci: remove ARCH_SUPPORTS_MSI kconfig option
Quoted 8 lines · Thomas Petazzoni
Dear Bjorn Helgaas,
Quoted 4 lines · Bjorn Helgaas
Acked-by Bjorn Helgaas <[email protected]>Again, please update the subject line to "PCI: Remove ..."
Quoted 8 lines
Quoted 3 lines
I doubt that you'll get explicit acks from all the arches you touched, but I think it's reasonable to put at least patches 2 & 3 in -next soon after v3.11-rc1, so we should have time to shake out issues.
Sure. Which merge strategy do you suggest for this patch series, which touches a number of different areas, and has some build-time dependencies between the patches (if needed, I can detail those build time dependencies to help figuring out the best strategy).
If we end up handling this the same as the of/pci & mvebu-pcie series (whole series through mvebu -> arm-soc) I can have it up in -next within a few days of -rc1. Just let me know.
hth,
Jason.
Bjorn Helgaas
maintainerPATCH v4 3/11 pci: remove ARCH_SUPPORTS_MSI kconfig option
Quoted 13 lines · Jason Cooper
Quoted 12 lines · Thomas Petazzoni
Dear Bjorn Helgaas,
Quoted 7 lines · Bjorn Helgaas
Acked-by Bjorn Helgaas <[email protected]>Again, please update the subject line to "PCI: Remove ..."
I doubt that you'll get explicit acks from all the arches you touched, but I think it's reasonable to put at least patches 2 & 3 in -next soon after v3.11-rc1, so we should have time to shake out issues.
Quoted 8 lines
Quoted 4 lines
Sure. Which merge strategy do you suggest for this patch series, which touches a number of different areas, and has some build-time dependencies between the patches (if needed, I can detail those build time dependencies to help figuring out the best strategy).
If we end up handling this the same as the of/pci & mvebu-pcie series (whole series through mvebu -> arm-soc) I can have it up in -next within a few days of -rc1. Just let me know.
That sounds fine with me. I don't think it's worth trying to split out the drivers/pci stuff and trying to coordinate it going through different trees.
PATCH v4 3/11 pci: remove ARCH_SUPPORTS_MSI kconfig option
Quoted 19 lines · Bjorn Helgaas
Quoted 18 lines · Jason Cooper
Quoted 16 lines · Thomas Petazzoni
Dear Bjorn Helgaas,
Quoted 7 lines · Bjorn Helgaas
Acked-by Bjorn Helgaas <[email protected]>Again, please update the subject line to "PCI: Remove ..."
I doubt that you'll get explicit acks from all the arches you touched, but I think it's reasonable to put at least patches 2 & 3 in -next soon after v3.11-rc1, so we should have time to shake out issues.
Sure. Which merge strategy do you suggest for this patch series, which touches a number of different areas, and has some build-time dependencies between the patches (if needed, I can detail those build time dependencies to help figuring out the best strategy).
Quoted 7 lines
Quoted 3 lines
If we end up handling this the same as the of/pci & mvebu-pcie series (whole series through mvebu -> arm-soc) I can have it up in -next within a few days of -rc1. Just let me know.
That sounds fine with me. I don't think it's worth trying to split out the
drivers/pcistuff and trying to coordinate it going through different trees.
Ok, will do.
Thomas, I assume there will be one more version to address Bjorn's last comments?
thx,
Jason.
PATCH v4 3/11 pci: remove ARCH_SUPPORTS_MSI kconfig option
Dear Jason Cooper,
Quoted 4 lines · Jason Cooper
Quoted 4 lines
Quoted 3 lines
If we end up handling this the same as the of/pci & mvebu-pcie series (whole series through mvebu -> arm-soc) I can have it up in -next within a few days of -rc1. Just let me know.
Quoted 8 lines
Quoted 3 lines
That sounds fine with me. I don't think it's worth trying to split out the
drivers/pcistuff and trying to coordinate it going through different trees.Ok, will do.
Thomas, I assume there will be one more version to address Bjorn's last comments?
Yes, indeed. I was waiting to see if Thierry Redding would give some additional feedback on Bjorn's comment, but if he doesn't, I'll resend an updated version, most likely next week.
Thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 4/11 PCI: Introduce new MSI chip infrastructure
In reply to Thomas PetazzoniFrom: Thierry Reding <[email protected]>
The new struct msi_chip is used to associated an MSI controller with a PCI bus. It is automatically handed down from the root to its children during bus enumeration.
This patch provides default (weak) implementations for the architecture- specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq() and arch_msi_check_device()) which check if a PCI device's bus has an attached MSI chip and forward the call appropriately.
--- drivers/pci/msi.c | 22 ++++++++++++++++++++++ drivers/pci/probe.c | 1 + include/linux/msi.h | 11 +++++++++++ include/linux/pci.h | 1 + 4 files changed, 35 insertions(+)
drivers/pci/msi.c +22 -0
@@ -32,15 +32,37 @@ static int pci_msi_enable = 1;int __weak arch_setup_msi_irq (struct pci_dev *dev,struct msi_desc *desc) { +struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->setup_irq) { +int err; + + err = chip->setup_irq (chip, dev, desc); +if (err <0 ) +return err; + +irq_set_chip_data (desc->irq, chip); +return err; + } +return -EINVAL ; }void __weak arch_teardown_msi_irq (unsigned int irq) { +struct msi_chip *chip =irq_get_chip_data (irq); + +if (chip && chip->teardown_irq) + chip->teardown_irq (chip, irq); }int __weak arch_msi_check_device (struct pci_dev *dev,int nvec,int type) { +struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->check_device) +return chip->check_device (chip, dev, nvec, type); +return 0 ; }
drivers/pci/probe.c +1 -0
@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent, child->parent = parent; child->ops = parent->ops; + child->msi = parent->msi; child->sysdata = parent->sysdata; child->bus_flags = parent->bus_flags;
include/linux/msi.h +11 -0
@@ -63,4 +63,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);void default_teardown_msi_irqs (struct pci_dev *dev); +struct msi_chip { +struct module *owner; +struct device *dev; + +int (*setup_irq)(struct msi_chip *chip,struct pci_dev *dev, +struct msi_desc *desc); +void (*teardown_irq)(struct msi_chip *chip,unsigned int irq); +int (*check_device)(struct msi_chip *chip,struct pci_dev *dev, +int nvec,int type); +}; +#endif /* LINUX_MSI_H */
include/linux/pci.h +1 -0
@@ -432,6 +432,7 @@ struct pci_bus {struct resource busn_res;/* bus numbers routed to this bus */ struct pci_ops *ops;/* configuration access functions */ +struct msi_chip *msi;/* MSI controller */ void *sysdata;/* hook for sys-specific extension */ struct proc_dir_entry *procdir;/* directory entry in /proc/bus/pci */
Signature · 1 line
1.8.1.2
Bjorn Helgaas
maintainerPATCH v4 4/11 PCI: Introduce new MSI chip infrastructure
Quoted 6 lines · Thomas Petazzoni
From: Thierry Reding <[email protected]>
The new struct
msi_chipis used to associated an MSI controller with a PCI bus. It is automatically handed down from the root to its children during bus enumeration.
Quoted 7 lines
This patch provides default (weak) implementations for the architecture- specific MSI functions (
arch_setup_msi_irq(),arch_teardown_msi_irq()andarch_msi_check_device()) which check if a PCI device's bus has an attached MSI chip and forward the call appropriately.Signed-off-by Thierry Reding <[email protected]>Signed-off-by Thomas Petazzoni <[email protected]>
I'm OK with this patch in principle, but I do have a couple comments below.
Quoted 19 lines
--- drivers/pci/msi.c | 22 ++++++++++++++++++++++ drivers/pci/probe.c | 1 + include/linux/msi.h | 11 +++++++++++ include/linux/pci.h | 1 + 4 files changed, 35 insertions(+)drivers/pci/msi.c +4
-0@@ -32,15 +32,37 @@ static int pci_msi_enable = 1;int __weak arch_setup_msi_irq (struct pci_dev *dev,struct msi_desc *desc) { +struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->setup_irq) { +int err;
drivers/pci/msi.c static int pci_msi_enable = 1; · line 48
Quoted 10 lines
drivers/pci/msi.c +9
-0+ + err = chip->setup_irq (chip, dev, desc); +if (err <0 ) +return err; + +irq_set_chip_data (desc->irq, chip); +return err; + } +return -EINVAL ;
It's sub-optimal to indent the whole body of a function like this. I think this is a bit more readable:
if (!chip || !chip->setup_irq)
return -EINVAL
err = chip->setup_irq(...);
...
return err;The return value of ->setup_irq() (and hence of arch_setup_msi_irq()) is a bit unclear. Apparently it can return negative values (errors) or positive values (not sure what they mean), or zero (again, not sure). A comment would clear this up.
It might even be worth introducing a no-op chip with pointers to no-op functions so we don't have to do these checks ("if (chip && chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on that -- certainly there are many examples of code that *does* make these checks everywhere -- so I'll ack it either way.
Quoted 7 lines
drivers/pci/msi.c +3
-0}void __weak arch_teardown_msi_irq (unsigned int irq) { +struct msi_chip *chip =irq_get_chip_data (irq); + +if (chip && chip->teardown_irq)
drivers/pci/msi.c static int pci_msi_enable = 1; · line 65
Quoted 10 lines
drivers/pci/msi.c +6
-0+ chip->teardown_irq (chip, irq); }int __weak arch_msi_check_device (struct pci_dev *dev,int nvec,int type) { +struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->check_device) +return chip->check_device (chip, dev, nvec, type); +
These functions are poorly named. They give no clue what "check_device" means. Are we checking that it exists, that it supports some property, that it's enabled, ... ?
Quoted 50 lines
drivers/pci/msi.c +0
-0return 0 ; }drivers/pci/probe.c +1
-0@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent, child->parent = parent; child->ops = parent->ops; + child->msi = parent->msi; child->sysdata = parent->sysdata; child->bus_flags = parent->bus_flags;include/linux/msi.h +11
-0@@ -63,4 +63,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);void default_teardown_msi_irqs (struct pci_dev *dev); +struct msi_chip { +struct module *owner; +struct device *dev; + +int (*setup_irq)(struct msi_chip *chip,struct pci_dev *dev, +struct msi_desc *desc); +void (*teardown_irq)(struct msi_chip *chip,unsigned int irq); +int (*check_device)(struct msi_chip *chip,struct pci_dev *dev, +int nvec,int type); +}; +#endif /* LINUX_MSI_H */ include/linux/pci.h +1
-1@@ -432,6 +432,7 @@ struct pci_bus {struct resource busn_res;/* bus numbers routed to this bus */ struct pci_ops *ops;/* configuration access functions */ +struct msi_chip *msi;/* MSI controller */ void *sysdata;/* hook for sys-specific extension */ struct proc_dir_entry *procdir;/* directory entry in /proc/bus/pci */ --1.8.1.2
PATCH v4 4/11 PCI: Introduce new MSI chip infrastructure
Dear Bjorn Helgaas,
Quoted 33 lines · Bjorn Helgaas
Quoted 19 lines
--- drivers/pci/msi.c | 22 ++++++++++++++++++++++ drivers/pci/probe.c | 1 + include/linux/msi.h | 11 +++++++++++ include/linux/pci.h | 1 + 4 files changed, 35 insertions(+)drivers/pci/msi.c +4
-0@@ -32,15 +32,37 @@ static int pci_msi_enable = 1;int __weak arch_setup_msi_irq (struct pci_dev *dev,struct msi_desc *desc) { +struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->setup_irq) { +int err;drivers/pci/msi.c static int pci_msi_enable = 1; · line 48
Quoted 10 lines
drivers/pci/msi.c +9
-0+ + err = chip->setup_irq (chip, dev, desc); +if (err <0 ) +return err; + +irq_set_chip_data (desc->irq, chip); +return err; + } +return -EINVAL ;It's sub-optimal to indent the whole body of a function like this. I think this is a bit more readable:
Quoted 6 lines
if (!chip || !chip->setup_irq)
return -EINVAL
err = chip->setup_irq(...);
...
return err;Right.
Quoted 4 lines
The return value of ->setup_irq() (and hence of
arch_setup_msi_irq()) is a bit unclear. Apparently it can return negative values (errors) or positive values (not sure what they mean), or zero (again, not sure). A comment would clear this up.
Ok, I'll have to look into this. Maybe Thierry Redding can comment on this.
Quoted 5 lines
It might even be worth introducing a no-op chip with pointers to no-op functions so we don't have to do these checks ("if (chip &&
chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on that -- certainly there are many examples of code that *does* make these checks everywhere -- so I'll ack it either way.
Ok, I'll see if it makes the overall thing cleaner.
Quoted 11 lines
drivers/pci/msi.c static int pci_msi_enable = 1; · line 65
Quoted 7 lines
drivers/pci/msi.c +5
-0int __weak arch_msi_check_device (struct pci_dev *dev,int nvec,int type) { +struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->check_device) +return chip->check_device (chip, dev, nvec, type); +These functions are poorly named. They give no clue what "
check_device" means. Are we checking that it exists, that it supports some property, that it's enabled, ... ?
Maybe Thierry Redding can comment on this one?
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 4/11 PCI: Introduce new MSI chip infrastructure
In reply to Bjorn HelgaasDear Bjorn Helgaas,
Quoted 27 lines · Bjorn Helgaas
Quoted 6 lines
int
__weakarch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc){drivers/pci/msi.c +4
-0+struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->setup_irq) { +int err;drivers/pci/msi.c static int pci_msi_enable = 1; · line 48
Quoted 10 lines
drivers/pci/msi.c +9
-0+ + err = chip->setup_irq (chip, dev, desc); +if (err <0 ) +return err; + +irq_set_chip_data (desc->irq, chip); +return err; + } +return -EINVAL ;It's sub-optimal to indent the whole body of a function like this. I think this is a bit more readable:
if (!chip || !chip->setup_irq) return -EINVAL err = chip->setup_irq(...); ... return err;
Quoted 4 lines
The return value of ->setup_irq() (and hence of
arch_setup_msi_irq()) is a bit unclear. Apparently it can return negative values (errors) or positive values (not sure what they mean), or zero (again, not sure). A comment would clear this up.
I've changed ->setup_irq() to simply return 0 on success, and a negative error code on failure.
Apparently, according to the default implementation
of arch_msi_setup_irqs(), the arch_msi_setup_irq() hook is supposed to return:
* A negative value on error, the value being an error code that is propagated to the caller.
* A positive value on some other errors, in which case the -ENOSPC error value is returned. To me, it doesn't make a lot of sense, as arch_msi_setup_irq() could just as well return -ENOSPC directly.
* A 0 value on success.
Quoted 5 lines
It might even be worth introducing a no-op chip with pointers to no-op functions so we don't have to do these checks ("if (chip &&
chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on that -- certainly there are many examples of code that *does* make these checks everywhere -- so I'll ack it either way.
The problem with this is that I'm not sure where in the PCI code this association to the default implementation should be done. And there are also two levels to take into account here:
* The PCI driver may not specify any msi_chip structure for a particular pci_bus. This would have to be detected by the PCI core when the bus is registered, and bus->msi would be set to the special no-op msi_chip.
* The PCI driver may specify an msi_chip structure, but without necessarily implementation all the methods. This could be solved by offering a pci_msi_chip_assign(struct pci_bus *, struct msi_chip *) function to be used by PCI drivers to assign their msi_chip to a given pci_bus, and this function would fill in the missing msi_chip operations with the default implementation.
I am not sure it is really worth doing at this point, but I'm open to suggestions on this.
Quoted 11 lines
drivers/pci/msi.c static int pci_msi_enable = 1; · line 65
Quoted 7 lines
int
__weakarch_msi_check_device(struct pci_dev *dev, int nvec, int type){drivers/pci/msi.c +5
-0+struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->check_device) +return chip->check_device (chip, dev, nvec, type); +These functions are poorly named. They give no clue what "
check_device" means. Are we checking that it exists, that it supports some property, that it's enabled, ... ?
Well the naming clearly doesn't come from this commit. The arch_msi_check_device() hook was around before this commit, and the reason the operation is named ->check_device() is just because it used the same terminology as the existing arch_msi_check_device() call.
This hook is only used in one place, the PowerPC architecture, in arch/powerpc/kernel/msi.c, to actually check whether the given device supports MSI.
I can rename if to arch_msi_device_supports_msi() and ->device_supports_msi(), or arch_msi_device_has_msi() and ->device_has_msi(), but that a change that relatively unrelated to this commit, I'd say.
Here as well, I'm open to suggestions,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 4/11 PCI: Introduce new MSI chip infrastructure
Quoted 1 line · Thomas Petazzoni
Dear Bjorn Helgaas,
Sorry for chiming in so late, I've had bad internet connectivity and email access for a few days.
Quoted 37 lines · Bjorn Helgaas
Quoted 28 lines
Quoted 7 lines
int
__weakarch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc){drivers/pci/msi.c +4
-0+struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->setup_irq) { +int err;drivers/pci/msi.c static int pci_msi_enable = 1; · line 48
Quoted 10 lines
drivers/pci/msi.c +9
-0+ + err = chip->setup_irq (chip, dev, desc); +if (err <0 ) +return err; + +irq_set_chip_data (desc->irq, chip); +return err; + } +return -EINVAL ;It's sub-optimal to indent the whole body of a function like this. I think this is a bit more readable:
if (!chip || !chip->setup_irq) return -EINVAL err = chip->setup_irq(...); ... return err;Quoted 4 lines
The return value of ->setup_irq() (and hence of
arch_setup_msi_irq()) is a bit unclear. Apparently it can return negative values (errors) or positive values (not sure what they mean), or zero (again, not sure). A comment would clear this up.I've changed ->setup_irq() to simply return 0 on success, and a negative error code on failure.
Quoted 9 lines
Apparently, according to the default implementation
ofarch_msi_setup_irqs(), thearch_msi_setup_irq()hook is supposed to return:
* A negative value on error, the value being an error code that is propagated to the caller.
* A positive value on some other errors, in which case the-ENOSPCerror value is returned. To me, it doesn't make a lot of sense, asarch_msi_setup_irq()could just as well return-ENOSPCdirectly.
* A 0 value on success.
Yes, I think that'd be much more straightforward. Having > 0 as a special case isn't useful here.
Quoted 6 lines
Quoted 5 lines
It might even be worth introducing a no-op chip with pointers to no-op functions so we don't have to do these checks ("if (chip &&
chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on that -- certainly there are many examples of code that *does* make these checks everywhere -- so I'll ack it either way.
Quoted 8 lines
The problem with this is that I'm not sure where in the PCI code this association to the default implementation should be done. And there are also two levels to take into account here:
* The PCI driver may not specify any
msi_chipstructure for a particularpci_bus. This would have to be detected by the PCI core when the bus is registered, andbus->msiwould be set to the special no-opmsi_chip.
You could check if bus->msi was set after the call to pcibios_bus_add() but that's a bit wonky because it may break once the first architecture appears that assigns it in a different place.
Quoted 9 lines
* The PCI driver may specify an
msi_chipstructure, but without necessarily implementation all the methods. This could be solved by offering apci_msi_chip_assign(struct pci_bus *, struct msi_chip *)function to be used by PCI drivers to assign theirmsi_chipto a givenpci_bus, and this function would fill in the missingmsi_chipoperations with the default implementation.I am not sure it is really worth doing at this point, but I'm open to suggestions on this.
I think these extra calls aren't that bad given how other alternatives are much easier to break things. Perhaps checking for the methods could be dropped, therefore making them mandatory (by crashing if they're not implemented).
Quoted 21 lines
Quoted 11 lines
drivers/pci/msi.c static int pci_msi_enable = 1; · line 65
Quoted 7 lines
int
__weakarch_msi_check_device(struct pci_dev *dev, int nvec, int type){drivers/pci/msi.c +5
-0+struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->check_device) +return chip->check_device (chip, dev, nvec, type); +These functions are poorly named. They give no clue what "
check_device" means. Are we checking that it exists, that it supports some property, that it's enabled, ... ?Well the naming clearly doesn't come from this commit. The
arch_msi_check_device()hook was around before this commit, and the reason the operation is named ->check_device() is just because it used the same terminology as the existingarch_msi_check_device()call.This hook is only used in one place, the PowerPC architecture, in
arch/powerpc/kernel/msi.c, to actually check whether the given device supports MSI.
Quoted 6 lines
I can rename if to
arch_msi_device_supports_msi()and ->device_supports_msi(), orarch_msi_device_has_msi()and ->device_has_msi(), but that a change that relatively unrelated to this commit, I'd say.Here as well, I'm open to suggestions,
I don't think *_check_device() is all that bad. Some of the implementations in PowerPC only use it to output a debug message, others do some more checking. Some of the checks look generic enough to move them into the core.
If you rename it to *_has_msi() or *_supports_msi() then I'd expect it to return a boolean and you loose the advantage of being able to return a more meaningful value. Although I'm not sure how useful that error code really is. It is passed all the way up to the caller of pci_enable_msi(), so a driver could use it to construct a better error message based on the error code. From a quick glance a few of them seem to do that.
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/20130709/d850b288/attachment.sig>
Bjorn Helgaas
maintainerPATCH v4 4/11 PCI: Introduce new MSI chip infrastructure
In reply to Thomas PetazzoniQuoted 31 lines · Thomas Petazzoni
Dear Bjorn Helgaas,
Quoted 27 lines · Bjorn Helgaas
Quoted 6 lines
int
__weakarch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc){drivers/pci/msi.c +4
-0+struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->setup_irq) { +int err;drivers/pci/msi.c static int pci_msi_enable = 1; · line 48
Quoted 10 lines
drivers/pci/msi.c +9
-0+ + err = chip->setup_irq (chip, dev, desc); +if (err <0 ) +return err; + +irq_set_chip_data (desc->irq, chip); +return err; + } +return -EINVAL ;It's sub-optimal to indent the whole body of a function like this. I think this is a bit more readable:
if (!chip || !chip->setup_irq) return -EINVAL err = chip->setup_irq(...); ... return err;
Quoted 7 lines
Quoted 4 lines
The return value of ->setup_irq() (and hence of
arch_setup_msi_irq()) is a bit unclear. Apparently it can return negative values (errors) or positive values (not sure what they mean), or zero (again, not sure). A comment would clear this up.I've changed ->setup_irq() to simply return 0 on success, and a negative error code on failure.
Perfect.
Quoted 32 lines
Apparently, according to the default implementation
ofarch_msi_setup_irqs(), thearch_msi_setup_irq()hook is supposed to return:
* A negative value on error, the value being an error code that is propagated to the caller.
* A positive value on some other errors, in which case the-ENOSPCerror value is returned. To me, it doesn't make a lot of sense, asarch_msi_setup_irq()could just as well return-ENOSPCdirectly.
* A 0 value on success.Quoted 5 lines
It might even be worth introducing a no-op chip with pointers to no-op functions so we don't have to do these checks ("if (chip &&
chip->xxx)" everywhere. I'm not sure if there's a Linux consensus on that -- certainly there are many examples of code that *does* make these checks everywhere -- so I'll ack it either way.The problem with this is that I'm not sure where in the PCI code this association to the default implementation should be done. And there are also two levels to take into account here:
* The PCI driver may not specify any
msi_chipstructure for a particularpci_bus. This would have to be detected by the PCI core when the bus is registered, andbus->msiwould be set to the special no-opmsi_chip.* The PCI driver may specify an
msi_chipstructure, but without necessarily implementation all the methods. This could be solved by offering apci_msi_chip_assign(struct pci_bus *, struct msi_chip *)function to be used by PCI drivers to assign theirmsi_chipto a givenpci_bus, and this function would fill in the missingmsi_chipoperations with the default implementation.
Quoted 2 lines
I am not sure it is really worth doing at this point, but I'm open to suggestions on this.
Sounds like it's not worth doing. Thanks for checking into it.
Quoted 21 lines
Quoted 11 lines
drivers/pci/msi.c static int pci_msi_enable = 1; · line 65
Quoted 7 lines
int
__weakarch_msi_check_device(struct pci_dev *dev, int nvec, int type){drivers/pci/msi.c +5
-0+struct msi_chip *chip = dev->bus->msi; + +if (chip && chip->check_device) +return chip->check_device (chip, dev, nvec, type); +These functions are poorly named. They give no clue what "
check_device" means. Are we checking that it exists, that it supports some property, that it's enabled, ... ?Well the naming clearly doesn't come from this commit. The
arch_msi_check_device()hook was around before this commit, and the reason the operation is named ->check_device() is just because it used the same terminology as the existingarch_msi_check_device()call.This hook is only used in one place, the PowerPC architecture, in
arch/powerpc/kernel/msi.c, to actually check whether the given device supports MSI.
Quoted 6 lines
I can rename if to
arch_msi_device_supports_msi()and ->device_supports_msi(), orarch_msi_device_has_msi()and ->device_has_msi(), but that a change that relatively unrelated to this commit, I'd say.Here as well, I'm open to suggestions,
You're right, you didn't make that mess, so I guess it's OK if you don't clean it up here. I spent a fair amount of time yesterday analyzing the return values, and lost interest before all became clear. So I stand by my assertion that it is hard to read, but I'm OK with leaving it as-is for now.
Bjorn
PATCH v4 5/11 of: pci: add registry of MSI chips
In reply to Thomas PetazzoniThis commit adds a very basic registry of msi_chip structures, so that an IRQ controller driver can register an msi_chip, and a PCIe host controller can find it, based on a 'struct device_node'.
--- drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++ include/linux/msi.h | 2 ++ include/linux/of_pci.h | 12 ++++++++++++ 3 files changed, 54 insertions(+)
drivers/of/of_pci.c +40 -0
@@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)return 0 ; }EXPORT_SYMBOL_GPL (of_pci_parse_bus_range); + +#ifdef CONFIG_PCI_MSI + +static LIST_HEAD (msi_chip_list); +static DEFINE_MUTEX (msi_chip_mutex); + +int of_msi_chip_add (struct msi_chip *chip) +{ +if (!of_property_read_bool (chip->of_node,"msi-controller" )) +return -EINVAL ; + +mutex_lock (&msi_chip_mutex); +list_add (&chip->list, &msi_chip_list); +mutex_unlock (&msi_chip_mutex); + +return 0 ; +} +EXPORT_SYMBOL_GPL (of_msi_chip_add); + +void of_msi_chip_remove (struct msi_chip *chip) +{ +mutex_lock (&msi_chip_mutex); +list_del (&chip->list); +mutex_unlock (&msi_chip_mutex); +} +EXPORT_SYMBOL_GPL (of_msi_chip_remove); + +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node) +{ +struct msi_chip *c; +list_for_each_entry (c, &msi_chip_list, list) { +if (c->of_node == of_node) +return c; + } + +return NULL ; +} +EXPORT_SYMBOL_GPL (of_find_msi_chip_by_node); + +#endif /* CONFIG_PCI_MSI */
include/linux/msi.h +2 -0
@@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);struct msi_chip {struct module *owner;struct device *dev; +struct device_node *of_node; +struct list_head list;int (*setup_irq)(struct msi_chip *chip,struct pci_dev *dev,struct msi_desc *desc);
include/linux/of_pci.h +12 -0
@@ -2,6 +2,7 @@#define __OF_PCI_H#include <linux/pci.h> +#include <linux/msi.h> struct pci_dev ;struct of_irq ;
@@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,int of_pci_get_devfn (struct device_node *np);int of_pci_parse_bus_range (struct device_node *node,struct resource *res); +#if defined(CONFIG_OF ) && defined(CONFIG_PCI_MSI ) +int of_msi_chip_add (struct msi_chip *chip); +void of_msi_chip_remove (struct msi_chip *chip); +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node); +#else +static inline int of_msi_chip_add (struct msi_chip *chip) {return -EINVAL ; } +static inline void of_msi_chip_remove (struct msi_chip *chip) { } +static inline struct msi_chip * +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL }; +#endif +#endif
Signature · 1 line
1.8.1.2
Bjorn Helgaas
maintainerPATCH v4 5/11 of: pci: add registry of MSI chips
Quoted 18 lines · Thomas Petazzoni
This commit adds a very basic registry of
msi_chipstructures, so that an IRQ controller driver can register anmsi_chip, and a PCIe host controller can find it, based on a 'structdevice_node'.Signed-off-by Thomas Petazzoni <[email protected]>--- drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++ include/linux/msi.h | 2 ++ include/linux/of_pci.h | 12 ++++++++++++ 3 files changed, 54 insertions(+)drivers/of/of_pci.c +0
-0@@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)return 0 ; }
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 100
Quoted 10 lines
drivers/of/of_pci.c +9
-0EXPORT_SYMBOL_GPL (of_pci_parse_bus_range); + +#ifdef CONFIG_PCI_MSI + +static LIST_HEAD (msi_chip_list); +static DEFINE_MUTEX (msi_chip_mutex); + +int of_msi_chip_add (struct msi_chip *chip) +{ +if (!of_property_read_bool (chip->of_node,"msi-controller" ))
The space between "! of_property..." is atypical.
Quoted 11 lines
drivers/of/of_pci.c +11
-0+return -EINVAL ; + +mutex_lock (&msi_chip_mutex); +list_add (&chip->list, &msi_chip_list); +mutex_unlock (&msi_chip_mutex); + +return 0 ; +} +EXPORT_SYMBOL_GPL (of_msi_chip_add); + +void of_msi_chip_remove (struct msi_chip *chip)
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 121
Quoted 10 lines
drivers/of/of_pci.c +10
-0+{ +mutex_lock (&msi_chip_mutex); +list_del (&chip->list); +mutex_unlock (&msi_chip_mutex); +} +EXPORT_SYMBOL_GPL (of_msi_chip_remove); + +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node) +{ +struct msi_chip *c;
Normally there's a blank line here.
The list traversal below isn't safe, is it? A simultaneous remove, e.g., of an MSI chip unrelated to the one we're looking up, might change the list while we're traversing it.
Quoted 54 lines
drivers/of/of_pci.c +10
-0+list_for_each_entry (c, &msi_chip_list, list) { +if (c->of_node == of_node) +return c; + } + + return NULL; +} +EXPORT_SYMBOL_GPL (of_find_msi_chip_by_node); + +#endif /* CONFIG_PCI_MSI */ include/linux/msi.h +2
-0@@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);struct msi_chip {struct module *owner;struct device *dev; +struct device_node *of_node; +struct list_head list;int (*setup_irq)(struct msi_chip *chip,struct pci_dev *dev,struct msi_desc *desc);include/linux/of_pci.h +12
-1@@ -2,6 +2,7 @@#define __OF_PCI_H#include <linux/pci.h> +#include <linux/msi.h> struct pci_dev ;struct of_irq ;@@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,int of_pci_get_devfn (struct device_node *np);int of_pci_parse_bus_range (struct device_node *node,struct resource *res); +#if defined(CONFIG_OF ) && defined(CONFIG_PCI_MSI ) +int of_msi_chip_add (struct msi_chip *chip); +void of_msi_chip_remove (struct msi_chip *chip); +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node); +#else +static inline int of_msi_chip_add (struct msi_chip *chip) {return -EINVAL ; } +static inline void of_msi_chip_remove (struct msi_chip *chip) { } +static inline struct msi_chip * +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL }; +#endif +#endif --1.8.1.2
PATCH v4 5/11 of: pci: add registry of MSI chips
Dear Bjorn Helgaas,
Quoted 5 lines · Bjorn Helgaas
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 100
Quoted 3 lines
drivers/of/of_pci.c +3
-0+int of_msi_chip_add (struct msi_chip *chip) +{ +if (!of_property_read_bool (chip->of_node,"msi-controller" ))The space between "!
of_property..." is atypical.
Indeed.
Quoted 9 lines
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 121
Quoted 3 lines
drivers/of/of_pci.c +3
-0+struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node) +{ +struct msi_chip *c;Normally there's a blank line here.
The list traversal below isn't safe, is it? A simultaneous remove, e.g., of an MSI chip unrelated to the one we're looking up, might change the list while we're traversing it.
True, will fix!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 5/11 of: pci: add registry of MSI chips
In reply to Thomas PetazzoniGrant, Rob,
Would it be possible to get your feeling about the below patch? Are you ok with the idea of this msi_chip registry, based on device_node pointer? This is the last piece of this patch set that needs an approval in terms of general approach.
I am at Linaro Connect this week, so if you want to discuss this live, do not hesitate to ping me.
Thanks a lot,
Thomas
Quoted 100 lines · Thomas Petazzoni
This commit adds a very basic registry of
msi_chipstructures, so that an IRQ controller driver can register anmsi_chip, and a PCIe host controller can find it, based on a 'structdevice_node'.Signed-off-by Thomas Petazzoni <[email protected]>--- drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++ include/linux/msi.h | 2 ++ include/linux/of_pci.h | 12 ++++++++++++ 3 files changed, 54 insertions(+)drivers/of/of_pci.c +40
-0@@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)return 0 ; }EXPORT_SYMBOL_GPL (of_pci_parse_bus_range); + +#ifdef CONFIG_PCI_MSI + +static LIST_HEAD (msi_chip_list); +static DEFINE_MUTEX (msi_chip_mutex); + +int of_msi_chip_add (struct msi_chip *chip) +{ +if (!of_property_read_bool (chip->of_node,"msi-controller" )) +return -EINVAL ; + +mutex_lock (&msi_chip_mutex); +list_add (&chip->list, &msi_chip_list); +mutex_unlock (&msi_chip_mutex); + +return 0 ; +} +EXPORT_SYMBOL_GPL (of_msi_chip_add); + +void of_msi_chip_remove (struct msi_chip *chip) +{ +mutex_lock (&msi_chip_mutex); +list_del (&chip->list); +mutex_unlock (&msi_chip_mutex); +} +EXPORT_SYMBOL_GPL (of_msi_chip_remove); + +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node) +{ +struct msi_chip *c; +list_for_each_entry (c, &msi_chip_list, list) { +if (c->of_node == of_node) +return c; + } + +return NULL ; +} +EXPORT_SYMBOL_GPL (of_find_msi_chip_by_node); + +#endif /* CONFIG_PCI_MSI */ include/linux/msi.h +2
-0@@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);struct msi_chip {struct module *owner;struct device *dev; +struct device_node *of_node; +struct list_head list;int (*setup_irq)(struct msi_chip *chip,struct pci_dev *dev,struct msi_desc *desc);include/linux/of_pci.h +12
-0@@ -2,6 +2,7 @@#define __OF_PCI_H#include <linux/pci.h> +#include <linux/msi.h> struct pci_dev ;struct of_irq ;@@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,int of_pci_get_devfn (struct device_node *np);int of_pci_parse_bus_range (struct device_node *node,struct resource *res); +#if defined(CONFIG_OF ) && defined(CONFIG_PCI_MSI ) +int of_msi_chip_add (struct msi_chip *chip); +void of_msi_chip_remove (struct msi_chip *chip); +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node); +#else +static inline int of_msi_chip_add (struct msi_chip *chip) {return -EINVAL ; } +static inline void of_msi_chip_remove (struct msi_chip *chip) { } +static inline struct msi_chip * +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL }; +#endif +#endif
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v4 5/11 of: pci: add registry of MSI chips
In reply to Thomas PetazzoniQuoted 16 lines · Thomas Petazzoni
This commit adds a very basic registry of
msi_chipstructures, so that an IRQ controller driver can register anmsi_chip, and a PCIe host controller can find it, based on a 'structdevice_node'.Signed-off-by Thomas Petazzoni <[email protected]>--- drivers/of/of_pci.c | 40 ++++++++++++++++++++++++++++++++++++++++ include/linux/msi.h | 2 ++ include/linux/of_pci.h | 12 ++++++++++++ 3 files changed, 54 insertions(+)drivers/of/of_pci.c +0
-0
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 98
Quoted 10 lines
drivers/of/of_pci.c +7
-0@@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)return 0 ; }EXPORT_SYMBOL_GPL (of_pci_parse_bus_range); + +#ifdef CONFIG_PCI_MSI + +static LIST_HEAD (msi_chip_list); +static DEFINE_MUTEX (msi_chip_mutex); + +int of_msi_chip_add (struct msi_chip *chip)
Perhaps of_pci_msi_chip_add instead.
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 111
Quoted 13 lines
drivers/of/of_pci.c +13
-0+{ +if (!of_property_read_bool (chip->of_node,"msi-controller" )) +return -EINVAL ; + +mutex_lock (&msi_chip_mutex); +list_add (&chip->list, &msi_chip_list); +mutex_unlock (&msi_chip_mutex); + +return 0 ; +} +EXPORT_SYMBOL_GPL (of_msi_chip_add); + +void of_msi_chip_remove (struct msi_chip *chip)
ditto
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 119
Quoted 8 lines
drivers/of/of_pci.c +8
-0+{ +mutex_lock (&msi_chip_mutex); +list_del (&chip->list); +mutex_unlock (&msi_chip_mutex); +} +EXPORT_SYMBOL_GPL (of_msi_chip_remove); + +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node)
ditto.
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 122
Quoted 3 lines
drivers/of/of_pci.c +3
-0+{ +struct msi_chip *c; +list_for_each_entry (c, &msi_chip_list, list) {
Need the safe variant here?
Rob
Quoted 58 lines
drivers/of/of_pci.c +9
-0+if (c->of_node == of_node) + return c; + } + +return NULL ; +} +EXPORT_SYMBOL_GPL (of_find_msi_chip_by_node); + +#endif /* CONFIG_PCI_MSI */ include/linux/msi.h +2
-0@@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);struct msi_chip {struct module *owner;struct device *dev; +struct device_node *of_node; +struct list_head list;int (*setup_irq)(struct msi_chip *chip,struct pci_dev *dev,struct msi_desc *desc);include/linux/of_pci.h +12
-1@@ -2,6 +2,7 @@#define __OF_PCI_H#include <linux/pci.h> +#include <linux/msi.h> struct pci_dev ;struct of_irq ;@@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,int of_pci_get_devfn (struct device_node *np);int of_pci_parse_bus_range (struct device_node *node,struct resource *res); +#if defined(CONFIG_OF ) && defined(CONFIG_PCI_MSI ) +int of_msi_chip_add (struct msi_chip *chip); +void of_msi_chip_remove (struct msi_chip *chip); +struct msi_chip *of_find_msi_chip_by_node (struct device_node *of_node); +#else +static inline int of_msi_chip_add (struct msi_chip *chip) {return -EINVAL ; } +static inline void of_msi_chip_remove (struct msi_chip *chip) { } +static inline struct msi_chip * +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL }; +#endif +#endif --1.8.1.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH v4 5/11 of: pci: add registry of MSI chips
Rob,
Quoted 3 lines · Rob Herring
Quoted 1 line
+int
of_msi_chip_add(struct msi_chip *chip)Perhaps
of_pci_msi_chip_addinstead.
Sure, makes sense.
Quoted 5 lines
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 122
Quoted 3 lines
drivers/of/of_pci.c +3
-0+{ +struct msi_chip *c; +list_for_each_entry (c, &msi_chip_list, list) {Need the safe variant here?
As suggested by Bjorn, I've changed this function to grab the msi_chip_mutex while traversing the list.
Does your e-mail implies that the general approach seems ok? If so, I'll resend an updated v5 version taking into account the comments that I have received on this v4.
Thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Bjorn Helgaas
maintainerPATCH v4 5/11 of: pci: add registry of MSI chips
Quoted 9 lines · Thomas Petazzoni
Quoted 5 lines · Rob Herring
drivers/of/of_pci.c int of_pci_parse_bus_range(struct device_node *node, struct resource *res) · line 122
Quoted 3 lines
drivers/of/of_pci.c +3
-0+{ +struct msi_chip *c; +list_for_each_entry (c, &msi_chip_list, list) {Need the safe variant here?
As suggested by Bjorn, I've changed this function to grab the
msi_chip_mutexwhile traversing the list.
The "safe" list functions don't do any mutual exclusion. The only safety they provide is that we won't go in the weeds if the body of the loop deletes the current list entry. This loop doesn't delete entries, so we don't need the safe variant.
Bjorn
PATCH v4 5/11 of: pci: add registry of MSI chips
In reply to Thomas PetazzoniQuoted 14 lines · Thomas Petazzoni
Rob,
Quoted 3 lines · Rob Herring
Quoted 1 line
+int
of_msi_chip_add(struct msi_chip *chip)Perhaps
of_pci_msi_chip_addinstead.Sure, makes sense.
Quoted 4 lines
Quoted 3 lines
drivers/of/of_pci.c +3
-0+{ +struct msi_chip *c; +list_for_each_entry (c, &msi_chip_list, list) {
Quoted 8 lines
Quoted 1 line
Need the safe variant here?
As suggested by Bjorn, I've changed this function to grab the
msi_chip_mutexwhile traversing the list.Does your e-mail implies that the general approach seems ok? If so, I'll resend an updated v5 version taking into account the comments that I have received on this v4.
Yes. Since it is only trivial comments, you can add my ack.
Rob
Quoted 5 lines
Thanks!
Thomas
PATCH v4 6/11 irqchip: armada-370-xp: properly request resources
In reply to Thomas PetazzoniInstead of using of_iomap(), we now use of_address_to_resource(), request_mem_region() and ioremap(). This allows the corresponding I/O regions to be properly requested and visible in /proc/iomem.
The main motivation for this change is that the introduction of the MSI support requires us to get the physical address of the main interrupt controller registers, so we will need the corresponding 'struct resource' anyway.
We also take this opportunity to change a panic() to BUG_ON(), in order to be consistent with the rest of the driver.
--- drivers/irqchip/irq-armada-370-xp.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
drivers/irqchip/irq-armada-370-xp.c +16 -4
@@ -248,12 +248,25 @@ armada_370_xp_handle_irq(struct pt_regs *regs)static int __init armada_370_xp_mpic_of_init (struct device_node *node,struct device_node *parent) { +struct resource main_int_res, per_cpu_int_res;u32 control; - main_int_base =of_iomap (node,0 ); - per_cpu_int_base =of_iomap (node,1 ); +BUG_ON (of_address_to_resource (node,0 , &main_int_res)); +BUG_ON (of_address_to_resource (node,1 , &per_cpu_int_res)); +BUG_ON (!request_mem_region (main_int_res.start, +resource_size (&main_int_res), + node->full_name)); +BUG_ON (!request_mem_region (per_cpu_int_res.start, +resource_size (&per_cpu_int_res), + node->full_name)); + + main_int_base =ioremap (main_int_res.start, +resource_size (&main_int_res));BUG_ON (!main_int_base); + + per_cpu_int_base =ioremap (per_cpu_int_res.start, +resource_size (&per_cpu_int_res));BUG_ON (!per_cpu_int_base); control =readl (main_int_base +ARMADA_370_XP_INT_CONTROL );
@@ -262,8 +275,7 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,irq_domain_add_linear (node, (control >>2 ) &0x3ff , &armada_370_xp_mpic_irq_ops,NULL ); -if (!armada_370_xp_mpic_domain) -panic ("Unable to add Armada_370_Xp MPIC irq domain (DT)\n" ); +BUG_ON (!armada_370_xp_mpic_domain);irq_set_default_host (armada_370_xp_mpic_domain);
Signature · 1 line
1.8.1.2
PATCH v4 7/11 irqchip: armada-370-xp: implement MSI support
In reply to Thomas PetazzoniThis commit introduces the support for the MSI interrupts in the armada-370-xp interrupt controller driver. It registers an MSI chip to the MSI chip registry, which will be used by the Marvell PCIe host controller driver.
The MSI interrupts use the 16 high doorbells, and are therefore notified using IRQ1 of the main interrupt controller.
--- .../devicetree/bindings/arm/armada-370-xp-mpic.txt | 3 + drivers/irqchip/irq-armada-370-xp.c | 141 ++++++++++++++++++++- 2 files changed, 143 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt +3 -0
@@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller Required properties: - compatible: Should be "marvell,mpic" - interrupt-controller: Identifies the node as an interrupt controller. +- msi-controller: Identifies the node as an PCI Message Signaled + Interrupt controller. - #interrupt-cells: The number of cells to define the interrupts. Should be 1. The cell is the IRQ number
@@ -24,6 +26,7 @@ Example: #address-cells = <1>; #size-cells = <1>; interrupt-controller; + msi-controller; reg = <0xd0020a00 0x1d0>, <0xd0021070 0x58>; };
drivers/irqchip/irq-armada-370-xp.c +140 -1
189 lines not on this page · raw message
Signature · 1 line
1.8.1.2
PATCH v4 8/11 arm: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci
In reply to Thomas PetazzoniSome PCI drivers may need to adjust the pci_bus structure after it has been allocated by the Linux PCI core. The PCI core allows architectures to implement the pcibios_add_bus() and pcibios_remove_bus() for this purpose. This commit therefore extends the hw_pci and pci_sys_data structures of the ARM PCI core to allow PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci, which will get called when a bus is added or removed from the system.
This will be used for example by the Marvell PCIe driver to connect a particular PCI bus with its corresponding MSI chip to handle Message Signaled Interrupts.
--- arch/arm/include/asm/mach/pci.h | 4 ++++ arch/arm/kernel/bios32.c | 16 ++++++++++++++++ 2 files changed, 20 insertions(+)
arch/arm/include/asm/mach/pci.h +4 -0
@@ -35,6 +35,8 @@ struct hw_pci {resource_size_t start, resource_size_t size, resource_size_t align); +void (*add_bus)(struct pci_bus *bus); +void (*remove_bus)(struct pci_bus *bus); };/*
@@ -62,6 +64,8 @@ struct pci_sys_data {resource_size_t start, resource_size_t size, resource_size_t align); +void (*add_bus)(struct pci_bus *bus); +void (*remove_bus)(struct pci_bus *bus);void *private_data;/* platform controller private data */ };
arch/arm/kernel/bios32.c +16 -0
@@ -363,6 +363,20 @@ void pcibios_fixup_bus(struct pci_bus *bus) }EXPORT_SYMBOL (pcibios_fixup_bus); +void pcibios_add_bus (struct pci_bus *bus) +{ +struct pci_sys_data *sys = bus->sysdata; +if (sys->add_bus) + sys->add_bus (bus); +} + +void pcibios_remove_bus (struct pci_bus *bus) +{ +struct pci_sys_data *sys = bus->sysdata; +if (sys->remove_bus) + sys->remove_bus (bus); +} +/* * Swizzle the device pin each time we cross a bridge. If a platform does * not provide a swizzle function, we perform the standard PCI swizzling.
@@ -463,6 +477,8 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head) sys->swizzle = hw->swizzle; sys->map_irq = hw->map_irq; sys->align_resource = hw->align_resource; + sys->add_bus = hw->add_bus; + sys->remove_bus = hw->remove_bus;INIT_LIST_HEAD (&sys->resources);if (hw->private_data)
Signature · 1 line
1.8.1.2
PATCH v4 9/11 arm: mvebu: the MPIC now provides MSI controller features
In reply to Thomas PetazzoniAdds the 'msi-controller' property to the main interrupt controller Device Tree node, to indicate that it can now behave as a MSI controller.
--- arch/arm/boot/dts/armada-370-xp.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/armada-370-xp.dtsi +1 -0
@@ -52,6 +52,7 @@ #interrupt-cells = <1>; #size-cells = <1>; interrupt-controller; + msi-controller; }; coherency-fabric at 20200 {
Signature · 1 line
1.8.1.2
PATCH v4 10/11 pci: mvebu: add support for MSI
In reply to Thomas PetazzoniThis commit adds support for Message Signaled Interrupts in the Marvell PCIe host controller. The work is very simple: it simply gets a reference to the msi_chip associated to the PCIe controller thanks to the msi-parent DT property, and stores this reference in the pci_bus structure. This is enough to let the Linux PCI core use the functions of msi_chip to setup and teardown MSIs.
--- .../devicetree/bindings/pci/mvebu-pci.txt | 3 +++ drivers/pci/host/pci-mvebu.c | 26 ++++++++++++++++++++++ 2 files changed, 29 insertions(+)
Documentation/devicetree/bindings/pci/mvebu-pci.txt +3 -0
@@ -12,6 +12,8 @@ Mandatory properties: - device_type, set to "pci" - ranges: ranges for the PCI memory and I/O regions, as well as the MMIO registers to control the PCIe interfaces. +- msi-parent: Link to the hardware entity that serves as the Message + Signaled Interrupt controller for this PCI controller. In addition, the Device Tree node must have sub-nodes describing each PCIe interface, having the following mandatory properties:
@@ -46,6 +48,7 @@ pcie-controller { #size-cells = <2>; bus-range = <0x00 0xff>; + msi-parent = <&mpic>; ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */ 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */
drivers/pci/host/pci-mvebu.c +26 -0
@@ -11,6 +11,7 @@#include <linux/clk.h> #include <linux/module.h> #include <linux/mbus.h> +#include <linux/msi.h> #include <linux/slab.h> #include <linux/platform_device.h> #include <linux/of_address.h>
@@ -107,6 +108,7 @@ struct mvebu_pcie_port;struct mvebu_pcie {struct platform_device *pdev;struct mvebu_pcie_port *ports; +struct msi_chip *msi;struct resource io;struct resource realio;struct resource mem;
@@ -695,6 +697,12 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)return bus; } +void mvebu_pcie_add_bus (struct pci_bus *bus) +{ +struct mvebu_pcie *pcie =sys_to_pcie (bus->sysdata); + bus->msi = pcie->msi; +} + resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev, const struct resource *res, resource_size_t start,
@@ -731,6 +739,7 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie) hw.map_irq = mvebu_pcie_map_irq; hw.ops = &mvebu_pcie_ops; hw.align_resource = mvebu_pcie_align_resource; + hw.add_bus = mvebu_pcie_add_bus;pci_common_init (&hw); }
@@ -755,6 +764,21 @@ mvebu_pcie_map_registers(struct platform_device *pdev,return devm_request_and_ioremap (&pdev->dev, ®s); } +static void __init mvebu_pcie_msi_enable (struct mvebu_pcie *pcie) +{ +struct device_node *msi_node; + + msi_node =of_parse_phandle (pcie->pdev->dev.of_node, +"msi-parent" ,0 ); +if (!msi_node) +return ; + + pcie->msi =of_find_msi_chip_by_node (msi_node); + +if (pcie->msi) + pcie->msi->dev = &pcie->pdev->dev; +} +static int __init mvebu_pcie_probe (struct platform_device *pdev) {struct mvebu_pcie *pcie;
@@ -879,6 +903,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev) i++; } +mvebu_pcie_msi_enable (pcie); +mvebu_pcie_enable (pcie);return 0 ;
Signature · 1 line
1.8.1.2
Bjorn Helgaas
maintainerPATCH v4 10/11 pci: mvebu: add support for MSI
Quoted 10 lines · Thomas Petazzoni
This commit adds support for Message Signaled Interrupts in the Marvell PCIe host controller. The work is very simple: it simply gets a reference to the
msi_chipassociated to the PCIe controller thanks to the msi-parent DT property, and stores this reference in thepci_busstructure. This is enough to let the Linux PCI core use the functions ofmsi_chipto setup and teardown MSIs.Signed-off-by Thomas Petazzoni <[email protected]>Reviewed-by Thierry Reding <[email protected]>Acked-by Bjorn Helgaas <[email protected]>
I've already acked this, and I reaffirm that. Please adjust the subject line to capitalize "PCI" and the first word of the descriptive sentence.
Quoted 101 lines
--- .../devicetree/bindings/pci/mvebu-pci.txt | 3 +++ drivers/pci/host/pci-mvebu.c | 26 ++++++++++++++++++++++ 2 files changed, 29 insertions(+)Documentation/devicetree/bindings/pci/mvebu-pci.txt +3
-0@@ -12,6 +12,8 @@ Mandatory properties: - device_type, set to "pci" - ranges: ranges for the PCI memory and I/O regions, as well as the MMIO registers to control the PCIe interfaces. +- msi-parent: Link to the hardware entity that serves as the Message + Signaled Interrupt controller for this PCI controller. In addition, the Device Tree node must have sub-nodes describing each PCIe interface, having the following mandatory properties:@@ -46,6 +48,7 @@ pcie-controller { #size-cells = <2>; bus-range = <0x00 0xff>; + msi-parent = <&mpic>; ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */ 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */drivers/pci/host/pci-mvebu.c +26
-1@@ -11,6 +11,7 @@#include <linux/clk.h> #include <linux/module.h> #include <linux/mbus.h> +#include <linux/msi.h> #include <linux/slab.h> #include <linux/platform_device.h> #include <linux/of_address.h> @@ -107,6 +108,7 @@ struct mvebu_pcie_port;struct mvebu_pcie {struct platform_device *pdev;struct mvebu_pcie_port *ports; +struct msi_chip *msi;struct resource io;struct resource realio;struct resource mem;@@ -695,6 +697,12 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)return bus; } +void mvebu_pcie_add_bus (struct pci_bus *bus) +{ +struct mvebu_pcie *pcie =sys_to_pcie (bus->sysdata); + bus->msi = pcie->msi; +} + resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev, const struct resource *res, resource_size_t start,@@ -731,6 +739,7 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie) hw.map_irq = mvebu_pcie_map_irq; hw.ops = &mvebu_pcie_ops; hw.align_resource = mvebu_pcie_align_resource; + hw.add_bus = mvebu_pcie_add_bus;pci_common_init (&hw); }@@ -755,6 +764,21 @@ mvebu_pcie_map_registers(struct platform_device *pdev,return devm_request_and_ioremap (&pdev->dev, ®s); } +static void __init mvebu_pcie_msi_enable (struct mvebu_pcie *pcie) +{ +struct device_node *msi_node; + + msi_node =of_parse_phandle (pcie->pdev->dev.of_node, +"msi-parent" ,0 ); +if (!msi_node) +return ; + + pcie->msi =of_find_msi_chip_by_node (msi_node); + +if (pcie->msi) + pcie->msi->dev = &pcie->pdev->dev; +} +static int __init mvebu_pcie_probe (struct platform_device *pdev) {struct mvebu_pcie *pcie;@@ -879,6 +903,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev) i++; } +mvebu_pcie_msi_enable (pcie); +mvebu_pcie_enable (pcie);return 0 ; --1.8.1.2
PATCH v4 11/11 arm: mvebu: link PCIe controllers to the MSI controller
In reply to Thomas PetazzoniThis commit adjusts the Armada 370 and Armada XP PCIe controllers Device Tree informations to reference their MSI controller. In the case of this platform, the MSI controller is implemented by the MPIC.
--- arch/arm/boot/dts/armada-370.dtsi | 1 + arch/arm/boot/dts/armada-xp-mv78230.dtsi | 1 + arch/arm/boot/dts/armada-xp-mv78260.dtsi | 1 + arch/arm/boot/dts/armada-xp-mv78460.dtsi | 1 + 4 files changed, 4 insertions(+)
arch/arm/boot/dts/armada-370.dtsi +1 -0
@@ -178,6 +178,7 @@ #address-cells = <3>; #size-cells = <2>; + msi-parent = <&mpic>; bus-range = <0x00 0xff>; ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
arch/arm/boot/dts/armada-xp-mv78230.dtsi +1 -0
@@ -91,6 +91,7 @@ #address-cells = <3>; #size-cells = <2>; + msi-parent = <&mpic>; bus-range = <0x00 0xff>; ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
arch/arm/boot/dts/armada-xp-mv78260.dtsi +1 -0
@@ -111,6 +111,7 @@ #address-cells = <3>; #size-cells = <2>; + msi-parent = <&mpic>; bus-range = <0x00 0xff>; ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
arch/arm/boot/dts/armada-xp-mv78460.dtsi +1 -0
@@ -127,6 +127,7 @@ #address-cells = <3>; #size-cells = <2>; + msi-parent = <&mpic>; bus-range = <0x00 0xff>; ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000 /* Port 0.0 registers */
Signature · 1 line
1.8.1.2