Date: Sat, 12 Oct 1996 01:29:39 +1000 (EST) From: michael butler <imb@asstdc.com.au> To: nao@sbl.cl.nec.co.jp (Naoki Hamada) Cc: current@freebsd.org Subject: Re: 3c589b + ep driver Message-ID: <199610111529.BAA00199@walkabout.asstdc.com.au> In-Reply-To: <199610090426.NAA20434@sirius.sbl.cl.nec.co.jp> from Naoki Hamada at "Oct 9, 96 01:26:51 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> I found that the ep driver does not properly handle commands which > take time more than a I/O cycle. What about the following patch? (This > patch is 961006-SNAP based. Still applicable to the current, I hope.) In your patch, you've moved some of the spin-loops to a position immediately after the command which requires the wait. Since there is often some code that is run between it and the next time we need to talk to the card, it's more efficient to do those calculations first and then wait for the card to become ready - it may actually be ready by then and we've constructively used the time we would have otherwise have spent waiting for it. In this case it doesn't change things very much because the delays are relatively short but, as a matter of efficiency, I tend to do this. I do find it confusing, however, if the spin-loop doesn't have an associated comment to document which command (possibly more than a screenful before) necessitated the wait so there's probably a balance in there somewhere .. > @@ -1289,6 +1291,7 @@ > } > all_pkt: > outw(BASE + EP_COMMAND, RX_DISCARD_TOP_PACK); > + EP_BUSY_WAIT; > /* > * recompute average packet's length, the factor used is 1/8 to go down > * and 1/32 to go up Unfortunately, my particular 589b wants the wait before the discard command else it drops link-OK and goes off into the never-never .. still trying to find out why :-( michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610111529.BAA00199>