Justin T. Gibbs wrote:
> I somewhat doubt that any CPU would hold onto a posted write for 200us
> since you are not guaranteed that a read will occur quickly and you want
> those write buffers to be availble for other clients, but regardless, the
> code has not been as you describe since November of last year.
Great, I stand corrected. Looks like 2.5 code is ancient then?
comments on the 2.4 code:
* the 1000us delay in ahc_reset needs to be turned into a sleep, instead
all paths to that function [AFAICS] can sleep. likewise for the huge
delay in ahc_acquire_seeprom.
* 400ms worst case udelay() is in ahc_clear_critical_section is kinda
annoying [but I suppose it can be lived with, if the average is a lot
less than that :)]
* the delay in ahc_init should be replaced with a sleep
* PCI posting? (aic7xxx_core.c, line 1322, the last statement in the
function...)
ahc_outb(ahc, CLRINT, CLRSCSIINT);
I'll look it over some more later.
-
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/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:40 EST