From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Fri, 12 Jul 2013 18:48:58 +0200
Subject: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
In-Reply-To: <51E01C0B.2000009@digi.com>
References: <1373583784-7129-1-git-send-email-marex@denx.de>
	<201307121401.29749.marex@denx.de> <51E01C0B.2000009@digi.com>
Message-ID: <201307121848.58405.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Hector,

[...]

> > Try Stefano's tree as Fabio suggested. I think it's already pushed and
> > includes the fixes.
> 
> I just tried, but it didn't help.

OK, then it's something else.

> >> Considering the other guys seem to work without problems I guess this
> >> scenario is specific to my board. I'm using a Micrel KSZ8031RNLI at
> >> 50MHz. I always suspect from the PHY.
> > 
> > You can try using the PHYLIB (CONFIG_PHYLIB and CONFIG_PHY_SMSC as in
> > sc_sps_1.h ) . Also, can you check which of the two "ret = -EINVAL" is
> > triggered in fec_send() ? You can add simple printf() alongside both of
> > them.
> 
> fec_send() *does not* ever fail

OK, it might be something else entirely. Let's take a look ...

> but I found something:
> It is very strange that the timeouts appear always after transferring
> between 20 and 24 MiB. So I thought maybe it was not an issue with the
> size of the file or the number of packets received, but instead a timed
> issue (an issue that happens after some period of time). I checked, and in
> fact the timeouts occur exactly 10 seconds after running the tftp command.
> I verified that this is what is happening by adding a udelay(100000) at
> fec_send(). In this case, the timeout also occurs after 10 seconds, but
> due to the delay, I have transferred only a few Kbytes.

Holy moly!

> I tried to change different timeout related constants at tftp.c but still
> the issue happens after 10s.
> It's like if, after these 10 seconds, the PHY lost the link or something.
> Really odd. Does it tell you anything?

LAN8720 phy, right? Try implementing something like [1], by clearing the 
EDPWRDOWN bit , the PHY will never enter low-power mode. It's just a simple PHY 
register RMW which you can stick somewhere into the PHY net/phy/smsc.c code.

[1] 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/djbw/dmaengine/+/b629820d18fa65cc598390e4b9712fd5f83ee693%5E!/#F0

Best regards,
Marek Vasut