[PARPORT] RE: patch-2.1.131-ac11-1284-2


Andrea Arcangeli (andrea@e-mind.com)
Wed, 16 Dec 1998 19:27:54 +0100 (CET)


On Wed, 16 Dec 1998, Tim Waugh wrote:

>> I also
>> reinserted the interrupt make sense message because I want to see when I
>> am really using irqs ;)
>
>If fast polling works, the semaphore will be upped but not downed. After a
>whole block of data is transferred using fast polling, the semaphore's count
>could be fairly high. Probably we should reset the semaphore (cleanly, and
>without introducing races) after we're happy that we don't need to wait.

I only want to know when the irq is effectively unblocking a process that
was sleeping on it.

Index: drivers/misc/parport_ieee1284.c
===================================================================
RCS file: /var/cvs/linux/drivers/misc/parport_ieee1284.c,v
retrieving revision 1.1.1.1.2.6
diff -u -r1.1.1.1.2.6 parport_ieee1284.c
--- parport_ieee1284.c 1998/12/16 14:18:28 1.1.1.1.2.6
+++ parport_ieee1284.c 1998/12/16 18:12:51
@@ -323,7 +323,7 @@
         }
 
 #ifdef DEBUG
- if (!atomic_read(&sem->count))
+ if (atomic_read(&sem->count) == -1)
                 DPRINTK (KERN_DEBUG "Woo hoo! Interrupt make sense!\n");
 #endif
         parport_ieee1284_wakeup (port);

>> Here the most important thing. Yesterday I didn' t understood well the
>> point of your code. That was emergency code that runs for 5
>> sec. If the port is shared we can' t really gain the port for such long
>> time.
>
>If we need the interrupts, we need to have the port claimed. No two ways
>about it. If the user wants to share devices, better poll instead.

No. The right but tricky way is to use irqs if there are no other
pardevevice in the parportwaitlist, and revert to polling as soon as
another pardevice claim the port.

>Were you getting "Woo hoo! Interrupt makes sense!" messages? If so, maybe
>the parport irq handling is wrong.

See the log in the last email. Everything seems fine though.

>Not sure about this.

It' s the thing I was talking about a bit above.

>> +#define REVERT_TO_POLLING \
>> +do { \
>> + sti(); \
>> + goto polling; \
>> +} while (0)
>> +
>> [...]
>> + } else
>> + REVERT_TO_POLLING;
>> + sti();
>> + }
>
>Don't use macros to comment your code -- use comments instead. ;-)

Hmm yes probably is better to resolve the macro in the source code ;)

Andrea Arcangeli

-- 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:18:57 EST