Re: [PARPORT] parport irq handler v7 test w/ 3 pp devices


grant@torque.net
Mon, 21 Sep 1998 07:42:35 -0400 (EDT)


> 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 KT adapter in the PHd drive is the most primitive one I've seen. It
supports nybble mode transfers only. My guess is that the time to do
the protocol exchange to read the device registers is almost always
long enough for the drive to get to the next state - so the driver never
has to wait for anything.

I'll think about adding a nice=2 option to force in a 1 tick sleep
somewhere. Finding the right place for it could be tricky.

> It is not that ECP is "evil", it is just useless for most parport hardware.

The phrase "ECP is evil" is mine, and refers mainly to the fact that
if a BIOS setting says "ECP/EPP" the PARIDE drivers are going to detect
it as SPP. So, EPP is good, but ECP spoils it :-)

> 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

Really ? My memory is often faulty, but I was using Linux back in the 0.99
days, and I remember having lp ...

--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------

-- 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