diff options
| author | Scott Feldman <sfeldma@pobox.com> | 2005-11-09 02:18:52 -0500 | 
|---|---|---|
| committer | Jeff Garzik <jeff@garzik.org> | 2007-04-28 11:01:05 -0400 | 
| commit | d52df4a35af569071fda3f4eb08e47cc7023f094 (patch) | |
| tree | b18fbd4ad63f3e19995d4b19017a44a02df9b707 /lib/kobject.c | |
| parent | 2933d42cb7b0f14e0f83f6f231c966e97c79cdc9 (diff) | |
[netdrvr e100] experiment with doing RX in a similar manner to eepro100
I was going to say that eepro100's speedo_rx_link() does the same DMA
abuse as e100, but then I noticed one little detail: eepro100 sets  both
EL (end of list) and S (suspend) bits in the RFD as it chains it  to the
RFD list.  e100 was only setting the EL bit.  Hmmm, that's  interesting.
That means that if HW reads a RFD with the S-bit set,  it'll process
that RFD and then suspend the receive unit.  The  receive unit will
resume when SW clears the S-bit.  There is no need  for SW to restart
the receive unit.  Which means a lot of the receive  unit state tracking
code in the driver goes away.
So here's a patch against 2.6.14.  (Sorry for inlining it; the mailer
I'm using now will mess with the word wrap).  I can't test this on
XScale (unless someone has an e100 module for Gumstix :) .  It should
be doing exactly what eepro100 does with RFDs.  I don't believe this
change will introduce a performance hit because the S-bit and EL-bit  go
hand-in-hand meaning if we're going to suspend because of the S- bit,
we're on the last resource anyway, so we'll have to wait for SW  to
replenish.
(cherry picked from 29e79da9495261119e3b2e4e7c72507348e75976 commit)
Diffstat (limited to 'lib/kobject.c')
0 files changed, 0 insertions, 0 deletions
