On Friday, March 29, 2013 05:50 AM, Tom Rini wrote:
On Mon, Mar 25, 2013 at 06:43:34AM -0000, Chris Ruehl wrote:
Hi,
I start a project on a freescale imx27 using the dm9000a for network.
I learned that the tftp , nfs and other network related working more less very unstable. I start compare the dm9000.c code with the upstream kernel v3.8.4 and fix some issues.
issues tftp with many bad checksums and timeouts nfs with not working at all when upload a 38Mbyte rootfs.jffs2
After the patch its works much better for me. please find my patch attached and consider to merge it the the head branch.
[snip]
@@ -351,75 +353,82 @@ static int dm9000_eth_rx (struct eth_device *edev) u32 tmplen, i; u32 tmpdata;
- udelay(2500); // we called in a loop to quick .. give me some time
No // style comments, and "We were called into the loop too quickly".
And I don't know if the big delay here is a good thing or not, without knowing the hardware. Jason, you've touched this driver recently and I assume know the hardware at least a little bit, can you comment here? For full context see http://patchwork.ozlabs.org/patch/230759/ thanks!
Tom,
yeah, .. sorry about the style, I'd missed the comment .. ( I gonna fix this and resend my patch later ..) you right about its hardware dependency, on the mx27 @ 400Mhz I tried it with delays from 1000-3000 where 2500 give me the best result. Without a delay its end up in tftp *TTTT#.. and NFS is not working at all.
Chris