Messages in this thread | | | From | "David Campbell" <> | Date | Sun, 1 Feb 1998 15:08:42 +0000 | Subject | Re: [PARPORT] Re: problems with parallel port IRQ detection |
| |
> 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"
| |