Messages in this thread | | | Date | Mon, 23 Sep 2002 18:50:33 -0400 | From | Jeff Garzik <> | Subject | Re: Quick aic7xxx bug hunt... |
| |
Justin T. Gibbs wrote: >>Great, I stand corrected. Looks like 2.5 code is ancient then? > > > Yes. I didn't do the original port and am now just finishing up my > port to 2.5.X. > > >>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. > > > For all of these delays, I'd be more than happy to make them all into > sleeps if I can tell, from inside ahc_delay() if I'm in a context where > it is safe to sleep. On the other platforms that this core code runs on > I'm usually not in a context where it is safe to sleep, so I don't want > to switch to using a different driver primitive.
For Linux it's unconditionally safe, and other platforms is sounds like it's unconditionally not. So, s/ahc_delay/ahc_sleep/ for the places I pointed out, and just make ahc_delay==ahc_sleep on non-Linux platforms (or any similarly-functioning solution)
It's pretty much impossible to detect if you are inside certain spinlocks, in a generic fashion.
>>* PCI posting? (aic7xxx_core.c, line 1322, the last statement in the >>function...) >> >> ahc_outb(ahc, CLRINT, CLRSCSIINT); > > > I don't care when the write occurs only that it will occur eventually. > The buffer will get flushed eventually so there is no need to call > ahc_flush_device_writes().
ok, thanks for clarifying.
Jeff
- 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/
| |