PCI parport irq sharing?
Hi,
Does parport_pc have the capability to share IRQs? I have a PCI parallel card with two ports on it:
parport0: PC-style at 0x3bc (0x7bc), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport1: PC-style at 0xc400 (0xc800), irq 9, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
parport1: irq 9 in use, resorting to polled operation
parport2: PC-style at 0xcc00 (0xd000) [PCSPP,TRISTATE]
parport0 is the mb's builtin parallel port, and parport1/parport2 are the two ports on the PCI card. IRQ 9 is taken by USB already. But since it's a modern PCI card, it would stand to reason that it should be able to share the IRQ with another PCI device, no? Unfortunately, my application requires interrupt-driven operation.
/proc/interrupts:
CPU0
0: 276501 XT-PIC timer 1: 1196 XT-PIC keyboard 2: 0 XT-PIC cascade 7: 7 XT-PIC parport0 8: 4 XT-PIC rtc 9: 2724988 XT-PIC acpi, usb-ohci 10: 8745 XT-PIC eth0 11: 0 XT-PIC CMI8738-MC4 12: 0 XT-PIC PS/2 Mouse 14: 16219 XT-PIC ide0 15: 29 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0
Kernel 2.4.24
thanks,
Signature · 1 line
Ryan Underwood, <[email protected]>
Quoted 35 lines · Ryan Underwood
Hi,
Does
parport_pchave the capability to share IRQs? I have a PCI parallel card with two ports on it:parport0: PC-style at
0x3bc(0x7bc), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport1: PC-style at0xc400(0xc800), irq 9, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
parport1: irq 9 in use, resorting to polled operation
parport2: PC-style at0xcc00(0xd000) [PCSPP,TRISTATE]parport0 is the mb's builtin parallel port, and parport1/parport2 are the two ports on the PCI card. IRQ 9 is taken by USB already. But since it's a modern PCI card, it would stand to reason that it should be able to share the IRQ with another PCI device, no? Unfortunately, my application requires interrupt-driven operation.
/proc/interrupts:
CPU00: 276501 XT-PIC timer 1: 1196 XT-PIC keyboard 2: 0 XT-PIC cascade 7: 7 XT-PIC parport0 8: 4 XT-PIC rtc 9: 2724988 XT-PIC acpi, usb-ohci 10: 8745 XT-PIC eth0 11: 0 XT-PIC CMI8738-MC4 12: 0 XT-PIC PS/2 Mouse 14: 16219 XT-PIC ide0 15: 29 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0
Quoted 7 lines
Kernel 2.4.24
thanks,
--
Ryan Underwood, <[email protected]>
To share interrupts requires that the interrupting device generate a level instead of an edge. The parallel ports that exist in "super I/O chips" and in bare boards, produce edges. If you have a special parallel port in a PCI slot, it should generate levels because the PCI specification demands that it does.
Since IRQ7 (the dedicated, edge, ISA parallel port interrupt) should never go to any PCI slot, I don't see how it could ever report using that. Perhaps it's a bug or the BIOS allowed it to be configured that way (remove IRQ7 from the PCI bus). This should make something else show up on the PCI bus. Move the board to another slot and see if the shared problem still remains.
The driver should be smart enough to know that if the interrupt was obtained from the PCI bus, then it can allocate it shared.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Quoted 19 lines · Richard B. Johnson
Quoted 11 lines
parport0: PC-style at
0x3bc(0x7bc), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport1: PC-style at0xc400(0xc800), irq 9, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
parport1: irq 9 in use, resorting to polled operation
parport2: PC-style at0xcc00(0xd000) [PCSPP,TRISTATE]parport0 is the mb's builtin parallel port, and parport1/parport2 are the two ports on the PCI card. IRQ 9 is taken by USB already. But since it's a modern PCI card, it would stand to reason that it should be able to share the IRQ with another PCI device, no? Unfortunately, my application requires interrupt-driven operation.
To share interrupts requires that the interrupting device generate a level instead of an edge. The parallel ports that exist in "super I/O chips" and in bare boards, produce edges. If you have a special parallel port in a PCI slot, it should generate levels because the PCI specification demands that it does.
Quoted 7 lines
Since IRQ7 (the dedicated, edge, ISA parallel port interrupt) should never go to any PCI slot, I don't see how it could ever report using that. Perhaps it's a bug or the BIOS allowed it to be configured that way (remove IRQ7 from the PCI bus). This should make something else show up on the PCI bus. Move the board to another slot and see if the shared problem still remains.
We might have talked past each other here. The IRQ7 is okay, because that's the motherboard's super I/O chip. The PCI parallel card is allocated IRQ9, which shares with USB and ACPI. However, the parport_pc driver doesn't seem to realize this is a PCI card and can share interrupts, hence the "irq %d in use, resorting to polled..." Worse, even if I find a free IRQ, I still can't use both the PCI card's parallel ports in interrupt-driven operation; as soon as one parport_pc is enabled on that IRQ, then the second parport can't use that IRQ anymore. Like the board is conflicting with itself....
My question was whether or not IRQ sharing was possible with the basic parport driver or not. If not, would something like parport_serial help me out here? Though, this is a NetMos card:
00:08.0 Communication controller: NetMos Technology VScom 021H-EP2 2 port parallel adaptor (rev 01)
and I don't think NetMos support has made it into parport_serial yet.
thanks,
Signature · 1 line
Ryan Underwood, <[email protected]>