On Mon, 5 Jun 2000, Petko Manolov wrote:
> Cyrille - i'll test your new patch later this evening.
> It looks little more verbose to me, but i think there
> is room for optimization. Basically i wish to URBify
There definitely is -- in particular, I'm not totally sure issuing resets
is really needed. Likewise, if I left some of the TX block resubmitting
logic, it needs deletion. Basically, I wanted to do whatever was needed to
get stability, at the cost of hideous code ; then, in a second phase, pick
up the interesting bits to make a nice driver. Because of (my) time
constraints, I've done only the first phase (and it seems my broken
hardware will demand some complements :( ), so the bits are up for
takers...
(it seems that PEGASUS_IN_RESET is useless, too. (ctrl_urb.status ==
-EINPROGRESS) gives the same result. Hmmm... Testing this right now).
> all pegasus_*_registers routines. The main problem is
> that i can't touch the registers from bottom-havves.
> I hope if URBifying work ok this will do the job.
It looks like URBifying may definitely help. However, URBifying also
means (to me) that whenever you do a lot of little control set/get
messages, you need to either :
a) split your routine (say, reset_MAC) into a bazillion little
routines which act as completion routine for operation N and submit
operation (N+1)
b) define a state machine (with perhaps sub-state machines for
longer operations like reset_MAC) and have a big multiplex in the
completion routine (hairy too. Reminds me of Petzold code).
Both solutions look ugly to me ; as I needed only one single
write_register operation, I've only URBified pegasus_set_register for
ad-hoc use.
-- Cyrille
------------------------------------------------------------------------------
Grumpf.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
