linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* PCI parport irq sharing?
@ 2004-01-08 18:16 Ryan Underwood
  2004-01-08 19:08 ` Richard B. Johnson
  0 siblings, 1 reply; 3+ messages in thread
From: Ryan Underwood @ 2004-01-08 18:16 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]


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,

-- 
Ryan Underwood, <nemesis@icequake.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PCI parport irq sharing?
  2004-01-08 18:16 PCI parport irq sharing? Ryan Underwood
@ 2004-01-08 19:08 ` Richard B. Johnson
  2004-01-09  1:38   ` Ryan Underwood
  0 siblings, 1 reply; 3+ messages in thread
From: Richard B. Johnson @ 2004-01-08 19:08 UTC (permalink / raw)
  To: Ryan Underwood; +Cc: Linux kernel

On Thu, 8 Jan 2004, Ryan Underwood wrote:

>
> 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,
>
> --
> Ryan Underwood, <nemesis@icequake.net>
>

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.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PCI parport irq sharing?
  2004-01-08 19:08 ` Richard B. Johnson
@ 2004-01-09  1:38   ` Ryan Underwood
  0 siblings, 0 replies; 3+ messages in thread
From: Ryan Underwood @ 2004-01-09  1:38 UTC (permalink / raw)
  To: Richard B. Johnson; +Cc: Ryan Underwood, Linux kernel

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

On Thu, Jan 08, 2004 at 02:08:19PM -0500, Richard B. Johnson wrote:
> >
> > 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.
> 
> 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.

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,

-- 
Ryan Underwood, <nemesis@icequake.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-01-09  1:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-08 18:16 PCI parport irq sharing? Ryan Underwood
2004-01-08 19:08 ` Richard B. Johnson
2004-01-09  1:38   ` Ryan Underwood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).