Roger Schreiter (Roger.Schreiter@Spectro21.de)
Fri, 17 Sep 1999 11:47:22 +0200
-------- Original Message --------
Subject: Re: Something I do not understand in the parport code
Date: Thu, 16 Sep 1999 19:39:01 +0100 (GMT)
From: Tim Waugh <tim@cyberelk.demon.co.uk>
To: Roger Schreiter <Roger.Schreiter@Spectro21.de>
Hi Roger,
On Thu, 16 Sep 1999, Roger Schreiter wrote:
> I'm currently working on introducing the "microsteps" in the
> parport-ieee1284-code.
That's good. Please be aware though that it's quite likely that the
only
bit of it to make it into 2.4 will be the necessary interface changes
(i.e. the new flag and possible a new function for aborting an
operation).
Linus has declared a feature freeze and may well consider this a
feature.
If there are interface changes necessary (and I think there will be) I
will try to make sure they are in though.
> You asked about, what to do, when a previous function is not finished.
>
> I think, those, who want to use those funcs atomically, should
> themselves pay attention.
>
> We replace things like
> port->ieee1284.phase = IEEE1284_PH_TERMINATE;
>
> by
> if (port->ieee1284.phase != IEEE1284_PH_TERMINATE) {
> port->ieee1284.phase = IEEE1284_PH_TERMINATE;
> port->ieee1284.microstep = IDLE;
> }
I'm not quite sure what you mean here.
[As an aside: when something is 'atomic' it means that either its
effects
are all visible at once, or never at all. Do you mean 'non-blocking',
or
do you mean 'without microsteps'? I'm guessing the latter.]
I'd rather not have ordinary client code (such as lp) have to worry
about
microsteps. It shouldn't need to know about them at all. I'm not even
sure that clever officejet code needs to know much about them either.
Just to clarify the change that's on the table, here's what I think
we're
doing:
An optimisation to improve system latency when the timeout on the port
is
zero. Currently we wait for 35ms _even_when_in_an_interrupt_, and the
'microstep' stuff should help to reduce that by remembering when we got
up
to, for next time the function is called. So, code like this:
port = parport_register_device (..., 0);
parport_claim_or_block (port);
parport_set_timeout (port, 0);
while (left) {
size_t wrote = port->ops->write_ecp_data (port, buf, left, 0);
[...]
left -= wrote;
if (need_resched) schedule (); /* with port held */
}
parport_release (port);
which would normally busy-wait for 35ms quite often, would just have to
change the register_device 'flags' parameter from 0 to
'PARPORT_FLAG_USE_MICROSTEPS' and busy-waiting would almost disappear.
This code isn't really very sensible -- the real win would be when the
write_ecp_data occurs inside an interrupt handler, in which case we just
have to be careful about leaving operations 'half-done'.
We need some way of aborting incomplete operations, and that could be
done
by passing 'PARPORT_FLAG_ABORT_OP' to write_ecp_data (or whichever
operation is incomplete). Or perhaps a port->ops->abort.
Do you agree that this is what we are both talking about? I don't want
us
to be talking about different things!
> There is one thing, I don't understand at all:
>
> if (!port->physport->cad->timeout)
> /* A zero timeout is "special": busy wait for the
> entire 35ms. */
> counter = 35000;
>
> for (counter /= 5; counter > 0; counter--) {
> status = parport_read_status (port);
> if ((status & mask) == result)
> return 0;
> if (signal_pending (current))
> return -EINTR;
> if (current->need_resched)
> break;
> udelay(5);
> }
>
> if (!port->physport->cad->timeout)
> /* We may be in an interrupt handler, so we can't poll
> * slowly anyway. */
> return 1;
>
> ... really? Does "(!port->physport->cad->timeout)" and a sleeping
> device not mean, that we have maybe already waited for 35000 usec?
Yes, but the difference is that we didn't sleep. udelay() just counts
in
a loop; it doesn't try to task-switch. An interrupt handler cannot
sleep,
but it can udelay.
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 Fri 17 Sep 1999 - 05:44:19 EDT