Re: [PARPORT] interrupt-driven lp

Philip Blundell (
Fri, 02 Jan 1998 18:01:24 +0000

>You added also the CVS directory.

Yes; Tim pointed that out already. Sorry about that.

>- lp run lp_error()
>- lp_error() run lp_schedule() that should sleep for LP_TIMEOUT_POLLED
> jiffies with the port _released_
>- lp_schedule exec parport_yield()

That's shouldn't happen. Let me try to explain again how the scheduling is
supposed to work.

This new function, parport_yield(), is intended solely to help the problem of
devices hogging the port for long periods. It's deliberately designed so that
you can call it quite often and not suffer too much needless overhead (this is
why it's inline and why it's important that it checks to see if anybody else
is waiting for the port). It's not supposed to replace parport_release in all
circumstances, just to get rid of the necessity for all devices to have
preempt/wakeup handlers and this "should_relinquish" mess.

The idea is that you call parport_yield() if you have reached a point at which
you _could_ give up the port (for lp this is basically at any time; for ppa
it would presumably be at the end of a command), but you could equally well
continue to own the port and make useful progress. In other words, it says to
the parport scheduler "you can take the port away from me now if you want and
nothing will go wrong, but I need it back as soon as it's free again". In a
lot of cases parport_yield() will do nothing at all, because it knows that
nobody else can make use of the port.

In the case of lp_error, the printer driver knows that it can't make any
progress for some time. In that situation you shouldn't call parport_yield()
at all; you should call parport_release(), wait for as long as you need, and
then call parport_claim_or_block() to regain access to the port.

I probably got this wrong when I put the new stuff into the lp driver, but
that's how it's supposed to work. Perhaps you could try and sort it out.


-- To unsubscribe, send mail to: --
-- 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:17 EST