Tim Waugh (twaugh@matra.co.uk)
Wed, 1 Sep 1999 10:48:46 +0100
Hi Roger,
I'm getting on a train in about half an hour, so I'll just quickly give you
my reaction to the mail you sent to the linux-parport list (which is cc'd).
Basically, your idea is still a good optimization, as in your original code.
The way things are done in Linus' tree is currently to busy-wait if our
timeout is zero, up to a maximum of 35ms. Yes, milliseconds(!). It's a
latency problem. It's okay for things like the printer console, but you
wouldn't want too many drivers busy-waiting in interrupts.
So I think that we do need something like what you suggest.
I would like to avoid having one function split into many different
micro-functions though, if possible. Perhaps something like the following
would be good:
int write(port)
{
switch (port->microstep) {
case IDLE: break; /* normal case */
case WCOMPAT_EVENT40: goto ev40; /* peripheral raises ack */
...
}
play_with_control_lines (port);
set_data_lines (port);
ev40:
/* Now we want the peripheral to notice us. */
if (wait_peripheral(port,x,y)) {
/* It didn't. */
if (!port->timeout)
/* We've got no timeout, so just remember where
* we got to. wait_peripheral may not have
* busy-waited for very long. */
port->microstep = WCOMPAT_EVENT40;
else {
/* We gave the peripheral the full 35ms, and
* nothing happened. Give up. */
set_data_to_abort (port);
set_ctrl_to_abort (port);
}
return count;
}
for (...) {
/* write stuff */
}
port->microstep = IDLE;
return count;
}
There are things to watch out for though:
- what if one function stops half-way through, but isn't called again? This
needs to be handled, and perhaps parport_set_timeout can fix-up when given a
non-zero parameter; but it's difficult to see how. Perhaps there ought to
be a flag for enabling/disabling this behaviour, so that drivers that don't
want to busy-wait have to explicitly tell parport that they're clever enough
to know to call a function until completion (or call a special function [a
new port->ops function] if they want to abort).
- what if one function stops half-way through and then a _different_
function is called next time? We have to make sure that the microstep
marker doesn't get misinterpreted by another routine. This is internal to
parport, and not related to any of its clients, so a naming convention would
suffice.
Tim.
*/
-- 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 01 Sep 1999 - 05:50:44 EDT