Andrea Arcangeli (arcangeli@mbox.queen.it)
Sun, 10 May 1998 17:07:13 +0200 (CEST)
On Sun, 10 May 1998, Francisco Rodrigo Escobedo Robles wrote:
>I am using 2.1.101. parport works ok with polling, but it stops a while and
>then resumes for a few lines when I try to print a "large" graphic (about
>100k).
Can I guess which printer are you using? You are using an HP and
more probably Deskjet.
The printer handshake is buggy.
I developed a kernel module called pscan (printer scanner) and the first
reports show a real bug in the printer handshake. Now all is clear to me.
Try pscan and give me the report so I can analyze your printer too. There'
s no README. You must compile and insmod ./pscan.o. Then you will see.
Also you must have 0x378 and irq 7 free (not used by the kernel at insmod
time). If your resources are different you must modify by hand two
#defines in pscan.c.
http://www.cs.unibo.it/~arcangel/pscan/pscan-0.3.tar.gz
I just developed a workaround for buggy printer (that is not in the
official kernel yet) since I want to work a bit more on the workaround to
be sure that it' s the best implementation.
I' ll try to explain what' s happening. This is the output of pscan on a
HP printer:
>tick: 3449253781, status: df, control: cc, type: 0.
>tick: 3449254522, status: 5f, control: dd, type: 0.
>tick: 3449254975, status: 5f, control: dc, type: 0.
^^
>tick: 3449255543, status: 1f, control: dc, type: 0.
>tick: 3449256550, status: 5f, control: dc, type: 1.
^^
>tick: 3449258367, status: df, control: dc, type: 0.
As you see the underlined lines have an equal status (and this is the
normal status before the interrupt) so lp think that the interrupt is not
happened yet also after type 1 (but type 1 means the interrupt is just
happened...).
The handshake of a _not_ buggy printer is (according to all specs I know):
___
ACK ______________________ ___________
|__|
____ \ interrupt here (or on the other edge)
BUSY _________ _____________
|____________|
HP instead use this handshake:
___
ACK _______________ ___________
|__|
____ \ interrupt here (or on the other edge)
BUSY _________ _____________
|____________|
| |
| |
\ /
here lp think the interrupt is not yet happend
and stall.
The only workaround I can imagine (and that I implemented), is to take
care of the interrupt using a volatile flag that is set by the irq handler
and that is zeroed after lp is wakenup _by_the_interrupt_. Then, when lp
is been waken_up _by_the_interrupt_, it must poll for a while to see BUSY
before continue.
Also the parport_sharing of lp must change a bit since lp can' t release
parport after has given to the printer the STROBE singal to not miss the
interrupt.
I just compiled a form (probably at best will answer me the webmaster ;-)
in the HP website to know if there' s something we can do to avoid the
buggy workaround, but I done that yesterday and I think nobody will answer
me before the next week so I' ll continue to work on the workaround to
make it cleaner and simper as possible, and I' ll sent it to Linus soon.
Only one question, should I mask the workaround code with an #ifdef
CONFIG_PRINTER_HP?
Andrea[s] 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:17:43 EST