Messages in this thread | | | Date | Mon, 27 Mar 2006 12:57:41 -0800 | From | "Jesse Brandeburg" <> | Subject | Re: [PATCH] Lower e100 latency |
| |
On 3/27/06, J.A. Magallon <jamagallon@able.es> wrote: > Corrected: > > --- linux/drivers/net/e100.c.orig 2006-01-24 09:20:44.000000000 +0100 > +++ linux/drivers/net/e100.c 2006-01-24 09:21:55.000000000 +0100 > @@ -884,10 +884,10 @@ > * procedure it should be done under lock. > */ > spin_lock_irqsave(&nic->mdio_lock, flags); > - for (i = 100; i; --i) { > + for (i = 1000; i; --i) { > if (readl(&nic->csr->mdi_ctrl) & mdi_ready) > break; > - udelay(20); > + udelay(2);
what is the purpose of this patch? what bug is it solving? Are we trying to achieve some goal? A comment at the very least is necessary. I don't like changing timing stuff unless we have some clear reason. In fact I sent a patch a while back to a guy who was complaining about latency in a -RT kernel with e100 and he said this kind of change made things worse: see the end of:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113808831932769&w=2
The problem in this case is the mii library calling back into our mdio_read. eepro100's mdio read hard spins with no delay besides the ioread32 delay created by reading from an i/o port. This could explain the glitching in an RT kernel.
Is this the kind of problem this patch tries to solve?
Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |