search for: pci_enable_msi

..., Jul 3, 2014 at 10:35 PM, Yijing Wang <wangyijing at huawei.com> wrote: >>> Hi Brian, >>> From your 01:00.0 VGA compatible controller PCI config register, it supports 1 MSI vector, so I think this >>> card has no problem. But you didn't answer what's the pci_enable_msi() return during it enable MSI fail. >>> >>> You can check PCI bus whether support MSI like: >>> >>> cat /sys/bus/pci/devices/00:0e.0/msi_bus >>> >>> Other, do you call pci_enable_device() before pci_enable_msi() ? >> >> Yes, the devi...

...4 at 10:35 PM, Yijing Wang <wangyijing at huawei.com> wrote: >>>> Hi Brian, >>>> From your 01:00.0 VGA compatible controller PCI config register, it supports 1 MSI vector, so I think this >>>> card has no problem. But you didn't answer what's the pci_enable_msi() return during it enable MSI fail. >>>> >>>> You can check PCI bus whether support MSI like: >>>> >>>> cat /sys/bus/pci/devices/00:0e.0/msi_bus >>>> >>>> Other, do you call pci_enable_device() before pci_enable_msi() ? >&gt...

...M, Yijing Wang <wangyijing at huawei.com> wrote: >>>>> Hi Brian, >>>>> From your 01:00.0 VGA compatible controller PCI config register, it supports 1 MSI vector, so I think this >>>>> card has no problem. But you didn't answer what's the pci_enable_msi() return during it enable MSI fail. >>>>> >>>>> You can check PCI bus whether support MSI like: >>>>> >>>>> cat /sys/bus/pci/devices/00:0e.0/msi_bus >>>>> >>>>> Other, do you call pci_enable_device() before pc...

...> + if (pmc->use_msi) > + nv_wr08(pmc->base.base.parent, 0x00088068, 0xff); Register not present everywhere. At the very least, the enabling of MSI should be disallowed on the earlier chipsets where it's not supported. Though, it's perhaps possible that the pci_enable_msi() call will fail in all of these cases anyway.. I'm not certain. > + > if (intr) { > nv_error(pmc, "unknown intr 0x%08x\n", stat); > } > @@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object) > struct nouveau_device...

...t;>>> by the fact that if we let nouveau enable MSI, the device doesn't work >>>> (presumably due to lack of interrupt delivery, although I admit to not >>>> having debugged it that far). How do I, as a nouveau driver developer, >>>> know not to call pci_enable_msi? Or alternatively how can >>>> pci_enable_msi be taught not to succeed in this case? >>> >>> You can set bus_flags or global pci_msi_enable flag by add quirk function. >>> You can refer to examples in drivers/pci/quirk.c >>> >>> Linux support...

...I think the situation is that MSI is > just not supported by the underlying motherboard, even though the > card, and probably bridge, support it just fine. It's a very old > board. The nouveau code does: What is the kernel version running in your board ? > > pmc->use_msi = pci_enable_msi(device->pdev) == 0; Driver call pci_enable_msi() and always return 0 ? > > Does it need to do more checking than that before trying to enable MSI > on the device? Could it be that the linux pci subsystem is missing on > inheriting MSI capabilities somewhere? pci_enable_msi() will...

On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang <wangyijing at huawei.com> wrote: > Hi Brian, > From your 01:00.0 VGA compatible controller PCI config register, it supports 1 MSI vector, so I think this > card has no problem. But you didn't answer what's the pci_enable_msi() return during it enable MSI fail. > > You can check PCI bus whether support MSI like: > > cat /sys/bus/pci/devices/00:0e.0/msi_bus > > Other, do you call pci_enable_device() before pci_enable_msi() ? Yes, the device is enabled. nouveau does generally work for most people :) And...

...nk 2 changed 11 -> 0 (XEN) irq.c:258: Dom1 PCI link 3 changed 5 -> 0 (XEN) irq.c:324: Dom1 callback via changed to PCI INTx Dev 0x03 IntC (XEN) Xen WARN at msi.c:635 (XEN) ----[ Xen-4.1.0.rc2.pre  x86_64  debug=y  Not tainted ]---- (XEN) CPU:    7 (XEN) RIP:    e008:[<ffff82c480161a08>] pci_enable_msi+0x464/0x960 (XEN) RFLAGS: 0000000000010206   CONTEXT: hypervisor (XEN) rax: 0000000000000000   rbx: 00000000dd6a0000   rcx: 0000000000000001 (XEN) rdx: ffff82c48025bc40   rsi: 0000000000000246   rdi: ffff82c48025bc40 (XEN) rbp: ffff830919aafdc8   rsp: ffff830919aafcf8   r8:  000000000000001a (XEN)...

...6935] iwlagn 0000:03:00.0: pci_resource_len = 0x00002000 [51230.646941] iwlagn 0000:03:00.0: pci_resource_base = ffffc9000671c000 [51230.646945] iwlagn 0000:03:00.0: HW Revision ID = 0x35 [51230.647075] iwlagn 0000:03:00.0: xen map irq failed -22 for 32752 domain [51230.647081] iwlagn 0000:03:00.0: pci_enable_msi failed [51230.647113] iwlagn 0000:03:00.0: PCI INT A disabled [51230.647126] iwlagn: probe of 0000:03:00.0 failed with error -22 with this on the Xen console (XEN) physdev.c:139: dom0: can''t create irq for msi! I''m running Xen as of a422e2a4451e, which your MSI changes in them...

...> On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang <wangyijing at huawei.com> wrote: >> Hi Brian, >> From your 01:00.0 VGA compatible controller PCI config register, it supports 1 MSI vector, so I think this >> card has no problem. But you didn't answer what's the pci_enable_msi() return during it enable MSI fail. >> >> You can check PCI bus whether support MSI like: >> >> cat /sys/bus/pci/devices/00:0e.0/msi_bus >> >> Other, do you call pci_enable_device() before pci_enable_msi() ? > > Yes, the device is enabled. nouveau does gen...

...t; by the fact that if we let nouveau enable MSI, the device doesn't work >>>>> (presumably due to lack of interrupt delivery, although I admit to not >>>>> having debugged it that far). How do I, as a nouveau driver developer, >>>>> know not to call pci_enable_msi? Or alternatively how can >>>>> pci_enable_msi be taught not to succeed in this case? >>>> >>>> You can set bus_flags or global pci_msi_enable flag by add quirk function. >>>> You can refer to examples in drivers/pci/quirk.c >>>> >&g...

...is confirmed >>> by the fact that if we let nouveau enable MSI, the device doesn't work >>> (presumably due to lack of interrupt delivery, although I admit to not >>> having debugged it that far). How do I, as a nouveau driver developer, >>> know not to call pci_enable_msi? Or alternatively how can >>> pci_enable_msi be taught not to succeed in this case? >> >> You can set bus_flags or global pci_msi_enable flag by add quirk function. >> You can refer to examples in drivers/pci/quirk.c >> >> Linux support some broken chipsets or...

...> diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index > 5798541..ec0a794 100644 > --- a/drivers/firewire/ohci.c > +++ b/drivers/firewire/ohci.c > @@ -3705,7 +3705,7 @@ static int pci_probe(struct pci_dev *dev, > if (!(ohci->quirks & QUIRK_NO_MSI)) > pci_enable_msi(dev); > if (request_irq(dev->irq, irq_handler, > - pci_dev_msi_enabled(dev) ? 0 : IRQF_SHARED, > + pci_dev_msi_enabled(dev, MSI_TYPE | MSIX_TYPE) ? 0 : > IRQF_SHARED, > ohci_driver_name, ohci)) { > ohci_err(ohci, "failed to allocate interrupt %d\n", dev-&...

...> diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index > 5798541..ec0a794 100644 > --- a/drivers/firewire/ohci.c > +++ b/drivers/firewire/ohci.c > @@ -3705,7 +3705,7 @@ static int pci_probe(struct pci_dev *dev, > if (!(ohci->quirks & QUIRK_NO_MSI)) > pci_enable_msi(dev); > if (request_irq(dev->irq, irq_handler, > - pci_dev_msi_enabled(dev) ? 0 : IRQF_SHARED, > + pci_dev_msi_enabled(dev, MSI_TYPE | MSIX_TYPE) ? 0 : > IRQF_SHARED, > ohci_driver_name, ohci)) { > ohci_err(ohci, "failed to allocate interrupt %d\n", dev-&...

...si) > > + nv_wr08(pmc->base.base.parent, 0x00088068, 0xff); > Register not present everywhere. > > At the very least, the enabling of MSI should be disallowed on the > earlier chipsets where it's not supported. Though, it's perhaps > possible that the pci_enable_msi() call will fail in all of these > cases anyway.. I'm not certain. > MSIs are required property for everything doing PCIe. So the only cases where this should fail is plain PCI/AGP devices. I don't really have a test system for those old cards set up. But I remember Ilia having some...

lspci shows MSI enabled for PCI device. PCI passthrough works fine. However, as soon as the MSI driver for card is insmodded, kernel panics. This is on xen-unstable. Tried the same with xen-3.3.0 which is supposed to have MSI passthrough, but the same guest shows MSI as disabled. Any else seen this bug, or know of a workaround ? Trace is as follows : ------------[ cut here ]------------

...l &= ~IOAT_PCI_DMACTRL_MSI_EN; diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 5798541..ec0a794 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -3705,7 +3705,7 @@ static int pci_probe(struct pci_dev *dev, if (!(ohci->quirks & QUIRK_NO_MSI)) pci_enable_msi(dev); if (request_irq(dev->irq, irq_handler, - pci_dev_msi_enabled(dev) ? 0 : IRQF_SHARED, + pci_dev_msi_enabled(dev, MSI_TYPE | MSIX_TYPE) ? 0 : IRQF_SHARED, ohci_driver_name, ohci)) { ohci_err(ohci, "failed to allocate interrupt %d\n", dev->irq); err = -EIO; diff -...

...nterrupt in two steps. >> If irq is the legacy interrupt, drivers will first >> use the irq_of_parse_and_map() or pci_enable_device() to parse and get the IRQ number. >> Then drivers will call the request_irq() to register the interrupt handler. >> If irq is MSIs, first call pci_enable_msi/x() to get the IRQ number and then call >> request_irq() to register interrupt handler. > > The method you describe here makes sense for PCI devices that are required to support > legacy interrupts and may or may not support MSI on a given system, but not so much > for platform d...

...nterrupt in two steps. >> If irq is the legacy interrupt, drivers will first >> use the irq_of_parse_and_map() or pci_enable_device() to parse and get the IRQ number. >> Then drivers will call the request_irq() to register the interrupt handler. >> If irq is MSIs, first call pci_enable_msi/x() to get the IRQ number and then call >> request_irq() to register interrupt handler. > > The method you describe here makes sense for PCI devices that are required to support > legacy interrupts and may or may not support MSI on a given system, but not so much > for platform d...

...> just not supported by the underlying motherboard, even though the > > card, and probably bridge, support it just fine. It's a very old > > board. The nouveau code does: > > > What is the kernel version running in your board ? > > > > > pmc->use_msi = pci_enable_msi(device->pdev) == 0; > > Driver call pci_enable_msi() and always return 0 ? > > > > > Does it need to do more checking than that before trying to enable MSI > > on the device? Could it be that the linux pci subsystem is missing on > > inheriting MSI capabilities s...