Re: Non-requested PCI IRQs unavailable to ISA PnP devices and pci_dev_uses_irq()

[Ondrej Zary]

On Friday 12 June 2009 22:38:17 you wrote:
> On Friday 12 June 2009 01:43:57 pm Ondrej Zary wrote:
> > Hello,
> > some PCI devices have an IRQ but the driver does not use it. Such an
> > example is matroxfb. It does request_irq() only for some vblank
> > operations. Thus, the irq is not marked as used in /proc/interrupts:
> >            CPU0
> >   0:     246481    XT-PIC-XT        timer
> >   1:       3507    XT-PIC-XT        i8042
> >   2:          0    XT-PIC-XT        cascade
> >   3:          1    XT-PIC-XT
> >   4:          1    XT-PIC-XT
> >   5:       4306    XT-PIC-XT        eth0
> >   6:          5    XT-PIC-XT        floppy
> >   7:          1    XT-PIC-XT        parport0
> >   8:          1    XT-PIC-XT        rtc
> >   9:          0    XT-PIC-XT        acpi
> >  11:      13748    XT-PIC-XT        pata_it821x, uhci_hcd:usb1
> >  12:      65539    XT-PIC-XT        i8042
> >  14:          0    XT-PIC-XT        ata_piix
> >  15:      33052    XT-PIC-XT        ata_piix
> > NMI:          0   Non-maskable interrupts
> > ERR:          0
> >
> > IRQ 10 is not listed but is used by one of the two Matrox cards:
> >
> > pci 0000:00:13.0: Boot video device
> > ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
> > PCI: setting IRQ 11 as level-triggered
> > matroxfb 0000:00:13.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) ->
> > IRQ 11
> > matroxfb: Matrox Mystique (PCI) detected
> > PInS memtype = 0
> > matroxfb: MTRR's turned on
> > matroxfb: 1024x768x8bpp (virtual: 1024x4096)
> > matroxfb: framebuffer at 0xE1000000, mapped to 0xd0880000, size 4194304
> > Console: switching to colour frame buffer device 128x48
> > fb0: MATROX frame buffer device
> > matroxfb 0000:00:14.0: enabling device (0000 -> 0002)
> > ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
> > PCI: setting IRQ 10 as level-triggered
> > matroxfb 0000:00:14.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) ->
> > IRQ 10
> > matroxfb: Matrox Millennium II (PCI) detected
> > PInS memtype = 0
> > matroxfb: MTRR's turned on
> > matroxfb: 1024x768x8bpp (virtual: 1024x4096)
> > matroxfb: framebuffer at 0xE3000000, mapped to 0xd1100000, size 4194304
> > fb1: MATROX frame buffer device
> > fb1: initializing hardware
> >
> >
> > But this interrupt is not available to ISA PnP devices because
> > drivers/pnp/resource.c calls pci_uses_irq() function which in turn calls
> > pci_dev_uses_irq() for all PCI devices. pci_dev_uses_irq() simply checks
> > the irq field in struct pci_dev.
> >
> > I wonder if that's correct (is it a bug or a feature)?
>
> The code that tries to keep PCI and PNP IRQs from clashing is
> definitely sub-optimal.  Of course, PNP doesn't know what the
> matroxfb driver doesn't need the interrupt.  Some drivers request
> and free the IRQ dynamically, depending on whether the device is
> in use.
>
> Maybe what we should be doing here is more sharing of PCI interrupts
> to leave more available for PNP.  For example, the 00:14.0 device
> that's currently using IRQ 10 is connected to a programmable IRQ
> link (LNKA).  Possibly that link could be programmed to share IRQ 11
> instead.
>
> In the absence of an automatic mechanism, can you work around this
> with the "acpi_irq_isa=10" kernel parameter?

Great, it works - both matrox cards are now at IRQ 11. Thanks for suggestion. 
Although it should not work according do Documentation/kernel-parameters.txt:

acpi_irq_isa=   [HW,ACPI] If irq_balance, mark listed IRQs used by ISA
                Format: <irq>,<irq>...

But this should apply to my machine:
acpi_irq_nobalance [HW,ACPI]
                ACPI will not move active IRQs (default)
                default in PIC mode


>
> Bjorn
>
> > I can't use CMI8239A sound card on my machine because of this (it needs
> > two IRQs). When I comment out that check (and move eth0 to IRQ3), the
> > sound card works, allocating IRQ 10 and 3 (with some modifications to
> > cmi8330 driver - will be posted separately).



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