[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C89507E.9040407@ti.com>
Date: Thu, 09 Sep 2010 17:24:14 -0400
From: Cyril Chemparathy <cyril@...com>
To: "Chemparathy, Cyril" <cyril@...com>
CC: Michael Williamson <michael.williamson@...ticallink.com>,
"davinci-linux-open-source@...ux.davincidsp.com"
<davinci-linux-open-source@...ux.davincidsp.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"tony@...mide.com" <tony@...mide.com>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
Hi Mike,
[...]
> An EMAC soft-reset clobbering the MDIO controller state is a
> possibility. I will poll TI designers to see if this could be the case.
To test this theory out, I hacked up a crude
beat-it-to-death-and-see-if-it-breaks kinda patch (attached). This
tests 10000 mdio read cycles while constantly doing an emac soft-reset.
I ran this on a dm365 evm, and the test didn't raise a single failed read:
> davinci_mdio davinci_mdio.0: davinci mdio revision 1.4
> davinci_mdio davinci_mdio.0: detected phy mask fffffffc
> 10000 test loops completed, 10000 reads ok
The failure in question seems to be limited to the da8xx family (tested
da830 evm), where:
> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
> davinci_mdio davinci_mdio.0: detected phy mask fffffff1
> idle triggered!!
The MDIO module upgrade (rev 1.4 -> 1.5) could have something to do with
this behavior. Even so, I can't explain why this issue wasn't seen on
da8xx prior to this series. The original code should (at least in
theory) have sporadically locked up on emac open.
Regards
Cyril.
View attachment "beat-emac-soft-reset.patch" of type "text/x-patch" (1936 bytes)
Powered by blists - more mailing lists