[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <5d7f4c9757838906e0adf01d77632f35@bga.com>
Date: Mon, 11 Jun 2007 10:58:44 -0500
From: Milton Miller <miltonm@....com>
To: Milton Miller <miltonm@....com>
Cc: Jeff Garzik <jeff@...zik.org>, Jeff Garzik <jgarzik@...ox.com>,
e1000-devel@...ts.sourceforge.net, David Acker <dacker@...net.com>,
netdev@...r.kernel.org,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
"Kok, Auke" <auke-jan.h.kok@...el.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
Scott Feldman <sfeldma@...ox.com>,
John Ronciak <john.ronciak@...el.com>
Subject: Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
On Jun 6, 2007, at 4:28 AM, Milton Miller wrote:
>
> On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:
>
>> Kok, Auke wrote:
>>>>
>>> Hmm git-revert seems to do the job right. I checked it with git-show
>>> | patch -p1 -R and the results look OK. The two patches on top of
>>> the one we want to revert are unrelated enough to apply (manually it
>>> shows some fuzz, but otherwise it's OK).
>>> Jeff, please `git-revert d52df4a35af569071fda3f4eb08e47cc7023f094`
>>> to revert the following patch for now:
>>> ---
>>> commit d52df4a35af569071fda3f4eb08e47cc7023f094
>>> Author: Scott Feldman <sfeldma@...ox.com>
>>> Date: Wed Nov 9 02:18:52 2005 -0500
>>> [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)
>>> ---
>>
>> A little bit more is needed to explain why we're reverting it for
>> now. Jeff, please insert this into the revert commit.
>>
>> Auke
>>
>> --
>> This patch attempted to fix e100 for non-cache coherent memory
>> architectures by using the cb style code that eepro100 had and using
>> the EL and s bits from the RFD list. Unfortunately the hardware
>> doesn't work exactly like this and therefore this patch actually
>> breaks e100 on those systems.
>
> on all systems. (Both the &| typo and the removed restart logic).
>
>> Reverting the change brings it back to the previously known good
>> state for 2.6.22. The pending rewrite in progress to this code can
>> then be safely merged later.
>>
>> Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com>
>>
Jeff I don't see this in netdev upstream-fixes. Are you waiting on
Auke to respond to this?
milton
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists