On Nov 5, 2005, at 2:28 AM, Lennert Buytenhek wrote:
On Fri, Nov 04, 2005 at 08:34:05PM -0800, Scott Feldman wrote:So there is nothing left. Why not just remove eepro100?This has been coming up every few months for a while now. e100 doesn'twork on a number of ARM platforms due to its (ab)use of the DMA API. http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1438.html http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/1481.html
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.
-scott
e100-s-bit.patch
Description: Binary data
