Re: [PARPORT] Re: problems with parallel port IRQ detection


David Campbell (campbell@gear.torque.net)
Sun, 1 Feb 1998 15:08:42 +0000


> To: "David Campbell" <campbell@gear.torque.net>
> Cc: "Jerod E. Tufte" <jet@jolt.com>, linux-kernel@vger.rutgers.edu,
> linux-parport@torque.net
> Subject: Re: [PARPORT] Re: problems with parallel port IRQ detection
> Date: Sun, 01 Feb 1998 00:55:42 +0000
> From: Philip Blundell <Philip.Blundell@pobox.com>

> >I have a few ideas to fix this problem, however I am extremely busy at
> >work for the next two weeks.
> >
> >When I wrote the original code it was to handle the situation of IRQ
> >sharing (I have a machine with full port count 3 LPT + 4 COM). This
> >required a slightly different IRQ probing scheme to that used previously
> >in Linux (which assumes that each IRQ is mapped to at most one device
> >driver).
>
> Just to clarify, the problem is _not_ with the IRQ-voting code that's in
> there. I'm pretty sure the problem is with the code that does this:
>
> irq = (parport_pc_read_configb(pb) >> 3) & 0x07;
>
> I've never understood how this was supposed to work, so I haven't been able to
> fix it.

*roll eyes*

Some chipset manufacturers use a couple of bits of the ecp config register
to indicate which IRQ the parallel port is tied to.

This is NOT (I repeat NOT) a reliable method for determining IRQs. (see
postscript).

>From the National Semiconductor manual, ECP CNFGB register (bits 0-7):
"Bits 5,4 These bits are 1 when IRQ5 is configured, and 0 when IRQ7 is
configured"

A quick calc shows the above formula is wrong (when in IRQ5 returns IRQ1).

There are "hard-wired" (actually jumpered) chipsets which do not report
the IRQ by the config registers. The only way to reliably detect the IRQ
is to perform data transfer and wait for the IRQ to arrive.

Please see .sig file for my opinions on trusting manufacturers data sheets
as gospel :-(.

The great thing about ECP is that you can fill the data buffer while in
"read" mode (by writing to the ECP data port [base+0x400]). According to
the ECP specs I have seen this simply adds data to the FIFO without
causing and transfer on the parallel port. After the FIFO is full, you
empty the FIFO (by reading from the ECP data port). Sooner or later you
will hit a trigger level where an IRQ is generated :=).

David Campbell

PS: I am not responsible for that formula....
=======================================================
campbell@torque.net (Parallel port device related mail)
dcampbel@p01.as17.honeywell.com.au (For all other mail)

"All parallel ports are equal - Some are more equal than others"

-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --



This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:17:22 EST