lkml.org 
[lkml]   [2006]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-03-27 23:00    [W:0.084 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site