David Campbell (campbell@torque.net)
Mon, 21 Sep 1998 18:35:26 +0800
> From: Boszormenyi Zoltan <zboszor@mol.hu>
> And two things I forgot:
>
> 1. When I use only the PHd or the PHd and the ZIP at the same time,
> the machine's responsiveness is very bad. But it is much better
> when printing comes in. Strange.
The "response" improvement is due to the lp driver yielding control
[via schedule()] while every other device is locked out. It sounds like
the PHd driver is capable of back-to-back IO without so much as
a timer tick between each request. (Grant?, please confirm)
The ZIP drive has a minimum of a single timer tick before a request
is issued (due to SCSI pedantics - if I didn't wait a timer tick, a race
condition would occur resulting in the kernel about 200+ calls deep
and panic due to "out of stack space").
There is a performance loss of around 5-10% in transfer speed for
good response gains, for most people this is OK. This is one of those
clasic engineering trade offs that need to be made.
> 2. All of you said before that "ECP is evil". I saw in the sources
> that parport can detect the irq if the port is set to ECP. I tried it
> and it really detected irq 7 but it said to set it through
> /proc/parport/0/irq
The problem with ECP is that it is designed for:
a) Printers
b) Scanners
Parallel port scanners are not supported by Linux (yet). The score
with parallel port printers leaves a little to be desired [**].
It is not that ECP is "evil", it is just useless for most parport hardware.
I wrote the IRQ detection code around a year ago, it was more an
attempt to figure out the IRQ for the lp driver. It works 95% of the time,
the other 5% of the time it fails for strange reasons hence the need
to use /proc entries to enable it.
> Ok, I figured that it may be an experimental
> feature. But I was surprised very much when the printer and the
> PHd were actually working! Setting the parallel port to ECP
> confused my printer and the PHd so much with the previous(*) parport
> version that I had to turn them off and on, sometimes I had to reboot
> and set the port back to EPP. So the parallel port mode changing is
> working reliably. More hip hip hooray! :)
Ehh?? I hope you are using a straight parport_pc?, not some wierd
parport_ns that I coded up about six months back. I plan to address
this area soon... [***]
Basically parport_pc can detect the ability of the hardware but not
force changes to the actual mode (other than saving a few ECP
config registers). This might of been previously broken, I certainly
hope that the config register swapping is working properly.
If you are really feeling brave I might be able to get that ECP printer
hack working for a real high speed lp driver (it will *only* work on
ECP ports hence it will never make the offical source code)
David Campbell
[**] The lp driver is woefully slow, this has more to do with the
fact that:
a) The XT parallel port was a rather brain dead design.
1] No method of detecting IRQ
2] IRQ support only suitable for old dotmatrix/PS printers
b) Lack of decent benchmark techniques.
How do you know if you have built a better lp driver?
Submissions most welcome, as long as they don't chew
through forrests.
c) The lp driver was more an after thought, it was one of the
very last drivers Linus added 0.99 to the kernel before rolling over
to 1.0.x
Remind me to send post the "pesudo device driver" for the
HP NetDirect. [Creates a FIFO and transfers the contents to
the relevant telnet port - idea here is a "virtual device file" that lpd
can dump stuff into...] I am away next week at a conference so don't
expect it in a hurry.
[***] Tim and Phil haven't answered a few parport implementation
questions I put to them about a week ago.
=======================================================
campbell@torque.net
Current project list:
a) Maintain Linux ZIP drivers
b) Create Linux chipset specific parport drivers
c) Start on ParSCSI drivers
d) Boot proms for parport devices (socket onto NE2000 cards)
Any assistance to clearing this list most welcome
-- 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:20 EST