Roger Schreiter (Roger.Schreiter@Spectro21.de)
Fri, 17 Sep 1999 12:28:47 +0200
Hi Tim,
thank you for your answer!
Tim Waugh wrote:
> ... 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).
> ...
If those changes will not get into the 2.4-kernels, we (HP OfficeJet team)
could perhaps provide a patch for the parport code inside the HP OfficeJet
package. But this makes only sense, when the changes of the parport code,
what we need, will one day become officiel kernel code. So if we find now
a solution for our "parport needs" which is accepted by the parport
team, it's ok for us, even if it will not become officiel 2.4. kernel code.
Thanks for your support!!!
> > 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.]
sorry, I meant: non-blocking.
> 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.
I agree, that every code which uses the parport funcs as they are now,
shouldn't
have to know anything about microsteps. I just thought, that a driver, that
uses the parport funcs, c a n tell parport to abort funcs, when a device
takes to long to answer.
> 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.
... so only the read or write funcs may return when the device is slow?
The nego-funcs e.g. will finish their work in almost every case (35 ms
timeout
never exceeded.) And when there are about 5
parport_wait_peripheral calls in a func, that func may wait up to
5 x 30 ms = 0.15 s, if a device almost consumes the whole timeout?
Do I understand right?
> ...
> Do you agree that this is what we are both talking about? I don't want us
> to be talking about different things!
> ...
> > ... 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.
> ...
May I get your opinion, whether the following idea will be o.k.:
A timer interrupt awakes a socket. The socket looks, whether there are
parport data available or wether the pardevice is again able to receive
data. When there is something to do, it activates a bottom half
(BH_IMMEDIATELY) for a function is called as soon as possible,
which will carry out the work. And that function may consume ap
to 0.15 s before returning (as extreme case). Will that be tolerable?
If that's o.k., I'll agree, that we won't have to change parport_wait_
peripheral, but only the read and write funcs, which call very often
parport_wait_peripheral.
Roger.
-- 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 - 06:29:29 EDT