Mugunthan and all,
We have essentially proven our theory, but have yet to solve the problem. Our
theory was that the driver was essentially taking a few second nap during
transmission, despite there being plenty more work to do. We further theorized
that our custom userspace application was
!
- Original Message -
From: Mugunthan V N mugunthan...@ti.com
To: CF Adad cfa...@rocketmail.com
Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org;
da...@davemloft.net da...@davemloft.net
Sent: Thursday, April 4, 2013 4:32 AM
Subject: Re: AM3517 DaVinci EMAC Ethernet performance issues
On 4/4
Mugunthan and all,
One more quick follow-up:
With that patch applied and us removing the SMSC LAN8710 PHY driver from the
kernel and just using the default unknown driver, things are *much* better.
(I have no idea why that PHY driver would be hurting us since that is the exact
PHY the
(( Attempting to re-post this since Yahoo! shipped the previous one as HTML...
))
All,
My team is presently seeing *extremely poor* (on the order of single-digit
Mbps) Ethernet performance out of an AM3517-based COM (Technexion's TAM-3517 in
this case) when it _transmits TCP_. Receiving TCP
I've tried getting this to the alsa-devel list, but have been a bit stymied.
Perhaps it would be relevant here too since this is directly related to the
OMAP world. As noted below, I suspect that recent changes from March in the
handling of McBSP1 (6-wire interface) on the omap2/3 are what is
I was able to determine it was a bug in the OMAP McBSP code. The following
patch fixed it for me.
--- linux-a/sound/soc/omap/mcbsp.c 2012-06-28 17:11:54.203508660 -0400
+++ linux-b/sound/soc/omap/mcbsp.c 2012-07-16 17:31:52.0 -0400
@@ -745,7 +745,7 @@
{
const char
Hi Kevin,
Thanks for the message! I did not realize the issue with the wake-ups affected
the EMAC, but I have been running my kernel with 'nohlt' since we transitioned
to linux-omap-3.4rcX several weeks back. It was required to keep the kernel
from crashing on boot. Running with that option
All,
Sorry to spam this out to so many folks, but we are REALLY getting stymied by
this bug at the moment and cannot believe we're the only ones seeing it.
Googles for this particular crash ONLY show this thread, and so far, no one has
responded. The folks CC'd on here have been kind enough
A quick follow-up note:
The stress line that was running during the crash mentioned was: stress --cpu
8 --io 8 --vm 1 --vm-bytes 150M --hdd 2 --timeout 60. The --hdd 2 option was
a leftover that was not supposed to be there. So that may have created a chunk
more disk work for the processor.
not believe Linux did anything with
them. Do I need to remove those in order to use your patches? If I do, do I
not lose access to those things while in the bootloaders?
Thanks
- Original Message -
From: Mohammed, Afzal af...@ti.com
To: CF Adad cfa...@rocketmail.com
Cc: linux-omap
We continue to try to sort this out. Ignoring the errors for a moment, has
anyone else experienced the performance slowdown quoted below between two EMACs?
If not, could anyone with two AM3517-baed platforms with the EMACs exposed
please test this for us? We've run several tests between all
An update:
*LAN9221 and GPMC off the hook?*
We've isolated the GPMC away from this I believe by disabling the LAN9221 in
both our bootloaders and the kernel and by booting everything off the SD cards
only. By removing it's initialization code from the respective board files, I
*hope* we've
incredibly odd... I'd be
very interested in knowing what others are seeing.
Thanks again for your comments!
- Original Message -
From: jean-philippe francois jp.franc...@cynove.com
To: CF Adad cfa...@rocketmail.com
Cc: Mohammed, Afzal af...@ti.com; linux-omap@vger.kernel.org
linux-omap
All,
I believe I may have uncovered a problem in the DaVinci EMAC driver as it is
used on the AM35xx. I suspect this is likely related to the slab crashing I
reported here (http://thread.gmane.org/gmane.linux.ports.arm.omap/78039/). Your
help and thoughts on this would be greatly appreciated.
as soon as I can.
Best regards!
- Original Message -
From: Mohammed, Afzal af...@ti.com
To: CF Adad cfa...@rocketmail.com
Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org; Tony Lindgren
t...@atomide.com; Shilimkar, Santosh santosh.shilim...@ti.com
Sent: Tuesday, June 12, 2012 7:14
! I may try fiddling a bit just to see if that helps.
- Original Message -
From: Mohammed, Afzal af...@ti.com
To: CF Adad cfa...@rocketmail.com
Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org; Tony Lindgren
t...@atomide.com; Shilimkar, Santosh santosh.shilim...@ti.com
Sent
- Original Message -
From: CF Adad cfa...@rocketmail.com
To: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org
Sent: Tuesday, June 5, 2012 12:29 PM
Subject: Re: Please help! AM35xx mm/slab.c BUG
Hi Tony,
Thanks so much for the response! All good
to dig into our operating system's space too
much.
Thanks again!
- Original Message -
From: Shilimkar, Santosh santosh.shilim...@ti.com
To: CF Adad cfa...@rocketmail.com
Cc: Tony Lindgren t...@atomide.com; linux-omap@vger.kernel.org
linux-omap@vger.kernel.org
Sent: Wednesday, June 6, 2012
# define M_NAND_GPMC_CONFIG7 0x0848
Any thoughts on that?
Thanks again. Your help is *greatly* appreciated.
- Original Message -
From: Tony Lindgren t...@atomide.com
To: Shilimkar, Santosh santosh.shilim...@ti.com
Cc: CF Adad cfa...@rocketmail.com; linux-omap@vger.kernel.org
linux-omap
a ton, only to disappear back into the vapor.
Thanks again for all your help and time. If we get any more points of interest
I'll certainly share.
- Original Message -
From: Jarkko Nikula jarkko.nik...@bitmer.com
To: Tony Lindgren t...@atomide.com
Cc: CF Adad cfa...@rocketmail.com
This seems to be something trivial, but so far we're stumped. The AM35xx has
the built-in DaVinci EMAC and the usual GPMC. Our board uses the EMAC coupled
with an SMSC LAN8710 PHY for one port, and a secondary port provided by a
LAN9221 wired up through the GPMC. The trouble is, if I enabled
All,
I'm **really** hoping someone out there can help us with this.
My team has been working with the AM3517 for several months now, and we seem to
be plagued every so often by what we have termed the slab bug. In short, it
looks something like the pasted bootlog below. This has been an
together they agree to dog it. Could this maybe be
related???
Thanks again for you time and help!
- Original Message -
From: Tony Lindgren t...@atomide.com
To: CF Adad cfa...@rocketmail.com
Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org
Sent: Tuesday, June 5, 2012 3:08 AM
these changes bring to
our effort isn't worth the time to correct it at the moment.
THANKS AGAIN FOR ALL YOUR HELP!
Hi,
On 03/05/12 19:32, CF Adad wrote:
Hi Igor,
Thanks for your reply! So are both ports working on the CM-T3517
simultaneously now?
Well, you
to me that the problem with running both is the mdio id setting.
Perhaps they're both demanding the same slot or something?
Thanks again for your reply. Please let me if I'm looking in the wrong place
for any of this or have this mixed up.
- Original Message -
From: CF Adad cfa
We have resolved our issue with the help of PaulM at TI. The driver does work,
the trouble was with the way the data was being masked in the buffer. We
posted a detailed explanation on the E2E forum (link above) that you may review
if interested. Thanks.
--
To unsubscribe from this list:
We have both a CompuLab CM-T3517 and a Technexion TAM-3517 at the shop. Both
boards provide dual Ethernet support in an identical fashion. One port uses
the onboard EMAC tied to an SMSC LAN87xx series PHY. The other is the old
trusty SMSC LAN911X hooked up to the GPMC.
Both boards support
One note of clarification:
As mentioned in the email above, the only non-standard piece to this
signaling is likely the long frame sync. As shown on the modem's timing
diagram (posted on the E2E forums here:
All,
Please forgive me if I don't get this post quite right. This is my first time
posting to the mailing lists.
My team is working on a driver that will be used to interface a cell modem's
digital audio interface (DAI) to a McBSP port on an AM3517. Our goal is to be
able to support multiple
29 matches
Mail list logo
