Tim Waugh (tim@cyberelk.demon.co.uk)
Tue, 15 Dec 1998 19:21:33 +0000 (GMT)
Hi Andrea,
> I don' t need to say that the CPU get very lighter efficiently used
> and being far to lose printing performance...
For me, the load is 0.00 while printing.
> +#if 0 /* this sucks every kind of irq handshake */
> /* 500usecs of fast polling.
> *
> * This should be adjustable.
> @@ -62,6 +63,7 @@
> break;
> udelay(25);
> }
> +#endif
>
> /* 40ms of slow polling. */
> init_timer (&timer);
Doesn't that kill polling? And interrupt-driven operation, for that matter?
Over the weekend I was getting only 100 characters/sec, and the reason was
the rc5des was eating the entire 10ms slice whenever the printer driver did
a schedule(). I was testing interrupt-driven printing at the time, and
had commented out the initial parport_wait_peripheral.
I'm _sure_ that polling fast to start off with will get good results, and
isn't a noticeable performance loss. (Remember, 0.00 load.)
> /* Handle an interrupt. */
> void parport_ieee1284_interrupt (int which, void *handle,
> struct pt_regs *regs)
> {
> struct parport *port = handle;
> +#ifdef DEBUG
> + struct semaphore *sem = &port->ieee1284.sem;
> +#endif
> if (!(port->cad->flags & PARPORT_DEV_IEEE1284IRQ)) {
> port->cad->flags |= PARPORT_DEV_IEEE1284IRQ;
> DPRINTK (KERN_DEBUG "Woo hoo! Using interrupts!\n");
> }
>
> +#ifdef DEBUG
> + if (!atomic_read(&sem->count))
> + DPRINTK (KERN_DEBUG "Woo hoo! Interrupt make sense!\n");
> +#endif
> parport_ieee1284_wakeup (port);
>
> if (port->ieee1284.phase == IEEE1284_PH_REV_IDLE) {
This looks dubious. All it means, if the semaphore is signalled, is that
fast polling may have worked before resorting to interrupts. If that were
_never_ true for anyone, perhaps I'd agree with your patch that takes out
fast polling.
> +#if 0
> /* Yield the port for a while. */
> if (count && polling (dev))
> parport_release (dev);
> +#endif
> [...]
> +#if 0
> if (count && polling (dev))
> parport_claim_or_block (dev);
> +#endif
What's up with that? The 'count' is there so that it doesn't do it the
first time, incidentally -- that means we can see if the driver's
giving us interrupts.
> /* Wait longer next time. */
> - if (wait < (port->ieee1284.timeout / 2))
> - wait *= 2;
> + if (wait < (port->ieee1284.timeout >> 1))
> + wait <<= 1;
Can't the compiler figure that out? Anyway, I think the 2s make the code
easier to read.
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 30 Dec 1998 - 10:18:55 EST