[PATCH 1/1] Fix sprz319 erratum 2.1

[PATCH 1/1] Fix sprz319 erratum 2.1

[Richard Watts]

There is an erratum in DM3730 which results in the
EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
leads to USB PHY clock drift and once the clock has drifted far
enough, the PHY's ULPI interface stops responding and USB
drops out. This is manifested on a Beagle xM by having the attached
SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
or similar.

The fix is to carefully adjust your DPLL5 settings so as to
keep the PHY clock as close as possible to 120MHz over the long
term; TI SPRZ319e gives a table of such settings and this patch
applies that table to systems with a 13MHz or a 26MHz clock,
thus fixing the issue (inasfar as it can be fixed) on Beagle xM
and Overo Firestorm.

Signed-off-by: Richard Watts <rrw@kynesim.co.uk>
---

 This is my first time submitting a kernel patch, so treat the
following with the respect it (doesn't) deserve. The way I'm
setting the dpll5_m2clk is particularly horrid, but the
previous code was not much better. An earlier version of
this patch appeared on the beagleboard mailing list.


 arch/arm/mach-omap2/clkt_clksel.c    |   15 ++++++++
 arch/arm/mach-omap2/clock.h          |    7 ++++
 arch/arm/mach-omap2/clock3xxx.c      |   65 +++++++++++++++++++++++++++++----
 arch/arm/mach-omap2/clock3xxx.h      |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/dpll3xxx.c       |    2 +-
 6 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_clksel.c b/arch/arm/mach-omap2/clkt_clksel.c
index e25364d..e378fe7 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -460,6 +460,21 @@ int omap2_clksel_set_rate(struct clk *clk, unsigned long rate)
 	return 0;
 }

+int omap2_clksel_force_divisor(struct clk *clk, int new_div)
+{
+	u32 field_val;
+
+	field_val = _divisor_to_clksel(clk, new_div);
+	if (field_val == ~0)
+		return -EINVAL;
+
+	_write_clksel_reg(clk, field_val);
+
+	clk->rate = clk->parent->rate / new_div;
+
+	return 0;
+}
+
 /*
  * Clksel parent setting function - not passed in struct clk function
  * pointer - instead, the OMAP clock code currently assumes that any
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index b8c2a68..5b149cd 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -61,6 +61,12 @@ void omap3_dpll_allow_idle(struct clk *clk);
 void omap3_dpll_deny_idle(struct clk *clk);
 u32 omap3_dpll_autoidle_read(struct clk *clk);
 int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate);
+#if CONFIG_ARCH_OMAP3
+int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16 freqsel);
+/* If you are using this function and not on OMAP3, you are
+ * Doing It Wrong(tm), so there is no stub.
+ */
+#endif
 int omap3_noncore_dpll_enable(struct clk *clk);
 void omap3_noncore_dpll_disable(struct clk *clk);
 int omap4_dpllmx_gatectrl_read(struct clk *clk);
@@ -86,6 +92,7 @@ unsigned long omap2_clksel_recalc(struct clk *clk);
 long omap2_clksel_round_rate(struct clk *clk, unsigned long target_rate);
 int omap2_clksel_set_rate(struct clk *clk, unsigned long rate);
 int omap2_clksel_set_parent(struct clk *clk, struct clk *new_parent);
+int omap2_clksel_force_divisor(struct clk *clk, int new_div);

 /* clkt_iclk.c public functions */
 extern void omap2_clkt_iclk_allow_idle(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock3xxx.c b/arch/arm/mach-omap2/clock3xxx.c
index 952c3e0..d5be086 100644
--- a/arch/arm/mach-omap2/clock3xxx.c
+++ b/arch/arm/mach-omap2/clock3xxx.c
@@ -40,6 +40,60 @@
 /* needed by omap3_core_dpll_m2_set_rate() */
 struct clk *sdrc_ick_p, *arm_fck_p;

+struct dpll_settings {
+	int rate, m, n, f;
+};
+
+
+static int omap3_dpll5_apply_erratum21(struct clk *clk, struct clk *dpll5_m2)
+{
+	struct clk *sys_clk;
+	int i, rv;
+	static const struct dpll_settings precomputed[] = {
+		/* From DM3730 errata (sprz319e), table 36
+		* +1 is because the values in the table are register values;
+		* dpll_program() will subtract one from what we give it,
+		* so ...
+		*/
+		{ 13000000, 443+1, 5+1, 8 },
+		{ 26000000, 443+1, 11+1, 8 }
+	};
+
+	sys_clk = clk_get(NULL, "sys_ck");
+
+	for (i = 0 ; i < (sizeof(precomputed)/sizeof(struct dpll_settings)) ;
+		++i) {
+		const struct dpll_settings *d = &precomputed[i];
+		if (sys_clk->rate == d->rate) {
+			rv =  omap3_noncore_dpll_program(clk, d->m , d->n, 0);
+			if (rv)
+				return 1;
+			rv =  omap2_clksel_force_divisor(dpll5_m2 , d->f);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+int omap3_dpll5_set_rate(struct clk *clk, unsigned long rate)
+{
+	struct clk *dpll5_m2;
+	int rv;
+	dpll5_m2 = clk_get(NULL, "dpll5_m2_ck");
+
+	if (cpu_is_omap3630() && rate == DPLL5_FREQ_FOR_USBHOST &&
+		omap3_dpll5_apply_erratum21(clk, dpll5_m2)) {
+		return 1;
+	}
+	rv = omap3_noncore_dpll_set_rate(clk, rate);
+	if (rv)
+		goto out;
+	rv = clk_set_rate(dpll5_m2, rate);
+
+out:
+	return rv;
+}
+
 int omap3_dpll4_set_rate(struct clk *clk, unsigned long rate)
 {
 	/*
@@ -59,19 +113,14 @@ int omap3_dpll4_set_rate(struct clk *clk, unsigned long rate)
 void __init omap3_clk_lock_dpll5(void)
 {
 	struct clk *dpll5_clk;
-	struct clk *dpll5_m2_clk;

 	dpll5_clk = clk_get(NULL, "dpll5_ck");
 	clk_set_rate(dpll5_clk, DPLL5_FREQ_FOR_USBHOST);
-	clk_enable(dpll5_clk);

-	/* Program dpll5_m2_clk divider for no division */
-	dpll5_m2_clk = clk_get(NULL, "dpll5_m2_ck");
-	clk_enable(dpll5_m2_clk);
-	clk_set_rate(dpll5_m2_clk, DPLL5_FREQ_FOR_USBHOST);
+	/* dpll5_m2_ck is now (grottily!) handled by dpll5_clk's set routine,
+	 * to cope with an erratum on DM3730
+	 */

-	clk_disable(dpll5_m2_clk);
-	clk_disable(dpll5_clk);
 	return;
 }

diff --git a/arch/arm/mach-omap2/clock3xxx.h b/arch/arm/mach-omap2/clock3xxx.h
index 8bbeeaf..0ede513 100644
--- a/arch/arm/mach-omap2/clock3xxx.h
+++ b/arch/arm/mach-omap2/clock3xxx.h
@@ -10,6 +10,7 @@

 int omap3xxx_clk_init(void);
 int omap3_dpll4_set_rate(struct clk *clk, unsigned long rate);
+int omap3_dpll5_set_rate(struct clk *clk, unsigned long rate);
 int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate);
 void omap3_clk_lock_dpll5(void);

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index d75e5f6..02f7676 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -942,7 +942,7 @@ static struct clk dpll5_ck = {
 	.parent		= &sys_ck,
 	.dpll_data	= &dpll5_dd,
 	.round_rate	= &omap2_dpll_round_rate,
-	.set_rate	= &omap3_noncore_dpll_set_rate,
+	.set_rate	= &omap3_dpll5_set_rate,
 	.clkdm_name	= "dpll5_clkdm",
 	.recalc		= &omap3_dpll_recalc,
 };
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fc56745..50ccee4 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -291,7 +291,7 @@ static void _lookup_sddiv(struct clk *clk, u8 *sd_div, u16 m, u8 n)
  * Program the DPLL with the supplied M, N values, and wait for the DPLL to
  * lock..  Returns -EINVAL upon error, or 0 upon success.
  */
-static int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16 freqsel)
+int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16 freqsel)
 {
 	struct dpll_data *dd = clk->dpll_data;
 	u8 dco, sd_div;
-- 
1.7.5.4

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2322 bytes --]

cc'ing beagleboard list, Kevin

Hi Richard,

thanks for the patch.  A quick question for you or anyone else who is 
experiencing this problem.

On Mon, 20 Feb 2012, Richard Watts wrote:

> There is an erratum in DM3730 which results in the
> EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
> leads to USB PHY clock drift and once the clock has drifted far
> enough, the PHY's ULPI interface stops responding and USB
> drops out. This is manifested on a Beagle xM by having the attached
> SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
> or similar.
> 
> The fix is to carefully adjust your DPLL5 settings so as to
> keep the PHY clock as close as possible to 120MHz over the long
> term; TI SPRZ319e gives a table of such settings and this patch
> applies that table to systems with a 13MHz or a 26MHz clock,
> thus fixing the issue (inasfar as it can be fixed) on Beagle xM
> and Overo Firestorm.
> 
> Signed-off-by: Richard Watts <rrw@kynesim.co.uk>

Funny, I just had a conversation with Kevin Hilman about needing to put 
the DPLL rate rounding code back in for the OPP tables.  This looks like 
another reason why...

Could you, or anyone else who is experiencing this problem on a board with 
a 26MHz oscillator try a quick test for me?  I'm a little curious about 
the (M, N) of (443, 12) that SPRZ319E is recommending.  Could you see if 
your USB problems are also solved by using (480, 13) ?

...

Here's the rationale.  Walking through the estimates here based on 
SPRZ319E, (443, 12) results in a frequency error of -166,667 Hz at the VCO 
output.  This is 174 ppm below the desired target rate of 960MHz.  But 
(480, 13) results in no frequency error.

The downside of using (480, 13) is that the PLL update interval increases 
from 461 ns to 500 ns (+9%).  But if the long-term drift of the DPLL is 
downward, then starting at a -174 ppm error has removed 35% of the total 
margin (+/- 500 ppm).  This might be too naïve, but a downward drift, 
seems likely given that gate delay increases as temperature increases.

Mainline is currently using (120, 13) which results in a VCO output 
frequency of 240MHz -- this presumably results in increased phase noise 
compared to (443, 12) and (480, 13) per SPRZ319E.  


- Paul

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2654 bytes --]

Hi,

On Fri, 24 Feb 2012, Paul Walmsley wrote:

> cc'ing beagleboard list, Kevin
> 
> Hi Richard,
> 
> thanks for the patch.  A quick question for you or anyone else who is 
> experiencing this problem.
> 
> On Mon, 20 Feb 2012, Richard Watts wrote:
> 
> > There is an erratum in DM3730 which results in the
> > EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
> > leads to USB PHY clock drift and once the clock has drifted far
> > enough, the PHY's ULPI interface stops responding and USB
> > drops out. This is manifested on a Beagle xM by having the attached
> > SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
> > or similar.
> > 
> > The fix is to carefully adjust your DPLL5 settings so as to
> > keep the PHY clock as close as possible to 120MHz over the long
> > term; TI SPRZ319e gives a table of such settings and this patch
> > applies that table to systems with a 13MHz or a 26MHz clock,
> > thus fixing the issue (inasfar as it can be fixed) on Beagle xM
> > and Overo Firestorm.
> > 
> > Signed-off-by: Richard Watts <rrw@kynesim.co.uk>
> 
> Funny, I just had a conversation with Kevin Hilman about needing to put 
> the DPLL rate rounding code back in for the OPP tables.  This looks like 
> another reason why...
> 
> Could you, or anyone else who is experiencing this problem on a board with 
> a 26MHz oscillator try a quick test for me?  I'm a little curious about 
> the (M, N) of (443, 12) that SPRZ319E is recommending.  Could you see if 
> your USB problems are also solved by using (480, 13) ?
> 
> ...
> 
> Here's the rationale.  Walking through the estimates here based on 
> SPRZ319E, (443, 12) results in a frequency error of -166,667 Hz at the VCO 
> output.  This is 174 ppm below the desired target rate of 960MHz.  But 
> (480, 13) results in no frequency error.
> 
> The downside of using (480, 13) is that the PLL update interval increases 
> from 461 ns to 500 ns (+9%).  But if the long-term drift of the DPLL is 
> downward, then starting at a -174 ppm error has removed 35% of the total 
> margin (+/- 500 ppm).  This might be too naïve, but a downward drift, 
> seems likely given that gate delay increases as temperature increases.
> 
> Mainline is currently using (120, 13) which results in a VCO output 
> frequency of 240MHz -- this presumably results in increased phase noise 
> compared to (443, 12) and (480, 13) per SPRZ319E.  

Just a quick followup on this.  Have you or anyone else out there tried 
this change?  Alternatively does someone out there have a test case that 
is simple to reproduce?  


- Paul

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[OCS]

[-- Attachment #1: Type: text/plain, Size: 3724 bytes --]

Hi ,

Robert N provided me with a kernel that has the patch in it. It seems to 
work in the test unit I have . Going to do more extensive tests* *next. 

The board i have essentially never goes beyond a few hrs with camera 
grabbing frames and ethernet activities going on. The cpu is constantly at 
90+ percent. Many times it would even hit the usb reset problem in a just 
few mins. 

With the patch it seems to be running so far overnight. 

If the extensive test fails, i would update the group again. 

Thanks to Robert and Richard for the patch!

cheers,
CS

On Thursday, July 12, 2012 5:19:37 PM UTC-4, Paul Walmsley wrote:
>
> Hi, 
>
> On Fri, 24 Feb 2012, Paul Walmsley wrote: 
>
> > cc'ing beagleboard list, Kevin 
> > 
> > Hi Richard, 
> > 
> > thanks for the patch.  A quick question for you or anyone else who is 
> > experiencing this problem. 
> > 
> > On Mon, 20 Feb 2012, Richard Watts wrote: 
> > 
> > > There is an erratum in DM3730 which results in the 
> > > EHCI USB PLL (DPLL5) not updating sufficiently frequently; this 
> > > leads to USB PHY clock drift and once the clock has drifted far 
> > > enough, the PHY's ULPI interface stops responding and USB 
> > > drops out. This is manifested on a Beagle xM by having the attached 
> > > SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?' 
> > > or similar. 
> > > 
> > > The fix is to carefully adjust your DPLL5 settings so as to 
> > > keep the PHY clock as close as possible to 120MHz over the long 
> > > term; TI SPRZ319e gives a table of such settings and this patch 
> > > applies that table to systems with a 13MHz or a 26MHz clock, 
> > > thus fixing the issue (inasfar as it can be fixed) on Beagle xM 
> > > and Overo Firestorm. 
> > > 
> > > Signed-off-by: Richard Watts <r...-XQiHveOWqdgqdlJmJB21zg@public.gmane.org <javascript:>> 
> > 
> > Funny, I just had a conversation with Kevin Hilman about needing to put 
> > the DPLL rate rounding code back in for the OPP tables.  This looks like 
> > another reason why... 
> > 
> > Could you, or anyone else who is experiencing this problem on a board 
> with 
> > a 26MHz oscillator try a quick test for me?  I'm a little curious about 
> > the (M, N) of (443, 12) that SPRZ319E is recommending.  Could you see if 
> > your USB problems are also solved by using (480, 13) ? 
> > 
> > ... 
> > 
> > Here's the rationale.  Walking through the estimates here based on 
> > SPRZ319E, (443, 12) results in a frequency error of -166,667 Hz at the 
> VCO 
> > output.  This is 174 ppm below the desired target rate of 960MHz.  But 
> > (480, 13) results in no frequency error. 
> > 
> > The downside of using (480, 13) is that the PLL update interval 
> increases 
> > from 461 ns to 500 ns (+9%).  But if the long-term drift of the DPLL is 
> > downward, then starting at a -174 ppm error has removed 35% of the total 
> > margin (+/- 500 ppm).  This might be too naïve, but a downward drift, 
> > seems likely given that gate delay increases as temperature increases. 
> > 
> > Mainline is currently using (120, 13) which results in a VCO output 
> > frequency of 240MHz -- this presumably results in increased phase noise 
> > compared to (443, 12) and (480, 13) per SPRZ319E.   
>
> Just a quick followup on this.  Have you or anyone else out there tried 
> this change?  Alternatively does someone out there have a test case that 
> is simple to reproduce?   
>
>
> - Paul

-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Frequently asked questions: http://beagleboard.org/faq

[-- Attachment #2: Type: text/html, Size: 4419 bytes --]

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Adrien Ferré]

[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]

Hi

We are facing this kind of issue on several beaglexm and panda es. We are 
currently seting up a test case which is:

Heavy network traffic:

A ftp server on the LAN serving one file to all boards.
All boards download the file, remove it, redownload it, ...

Heavy usb traffic:

We have to USB-Serial adapters wired together at 115200 with RTS/CTS 
enabled and serving a file to each other simultaneously.

We'll run the tests for a few days and I'll give the results here.

OCS: do you have results to provide for your tests please?

Le vendredi 24 février 2012 23:13:57 UTC+1, Paul Walmsley a écrit :
>
> cc'ing beagleboard list, Kevin
>
> Hi Richard,
>
> thanks for the patch.  A quick question for you or anyone else who is 
> experiencing this problem.
>
> On Mon, 20 Feb 2012, Richard Watts wrote:
>
> > There is an erratum in DM3730 which results in the
> > EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
> > leads to USB PHY clock drift and once the clock has drifted far
> > enough, the PHY's ULPI interface stops responding and USB
> > drops out. This is manifested on a Beagle xM by having the attached
> > SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
> > or similar.
> > 
> > The fix is to carefully adjust your DPLL5 settings so as to
> > keep the PHY clock as close as possible to 120MHz over the long
> > term; TI SPRZ319e gives a table of such settings and this patch
> > applies that table to systems with a 13MHz or a 26MHz clock,
> > thus fixing the issue (inasfar as it can be fixed) on Beagle xM
> > and Overo Firestorm.
> > 
> > Signed-off-by: Richard Watts <r...-XQiHveOWqdgqdlJmJB21zg@public.gmane.org <javascript:>>
>
> Funny, I just had a conversation with Kevin Hilman about needing to put 
> the DPLL rate rounding code back in for the OPP tables.  This looks like 
> another reason why...
>
> Could you, or anyone else who is experiencing this problem on a board with 
> a 26MHz oscillator try a quick test for me?  I'm a little curious about 
> the (M, N) of (443, 12) that SPRZ319E is recommending.  Could you see if 
> your USB problems are also solved by using (480, 13) ?
>
> ...
>
> Here's the rationale.  Walking through the estimates here based on 
> SPRZ319E, (443, 12) results in a frequency error of -166,667 Hz at the VCO 
> output.  This is 174 ppm below the desired target rate of 960MHz.  But 
> (480, 13) results in no frequency error.
>
> The downside of using (480, 13) is that the PLL update interval increases 
> from 461 ns to 500 ns (+9%).  But if the long-term drift of the DPLL is 
> downward, then starting at a -174 ppm error has removed 35% of the total 
> margin (+/- 500 ppm).  This might be too naïve, but a downward drift, 
> seems likely given that gate delay increases as temperature increases.
>
> Mainline is currently using (120, 13) which results in a VCO output 
> frequency of 240MHz -- this presumably results in increased phase noise 
> compared to (443, 12) and (480, 13) per SPRZ319E.  
>
>
> - Paul
>
>

-- 
For more options, visit http://beagleboard.org/discuss



[-- Attachment #2: Type: text/html, Size: 3748 bytes --]

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Adrien Ferré]

[-- Attachment #1: Type: text/plain, Size: 5457 bytes --]

Hi

The tests have been running for 6 days now and we had only one failing BBxm

There are five boards:

2 panda: high network + usb traffic
3 bbxm: high network + usb traffic

The only error we got was on a bbxm after 40 hours or so, see log below:


[81288.126525] usb 1-2.4: new full-speed USB device number 8 using ehci-omap
[81288.252624] usb 1-2.4: New USB device found, idVendor=0403, 
idProduct=6001
[81288.252655] usb 1-2.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[81288.252685] usb 1-2.4: Product: FT232R USB UART
[81288.252716] usb 1-2.4: Manufacturer: FTDI
[81288.252746] usb 1-2.4: SerialNumber: A401180G
[81288.264221] ftdi_sio 1-2.4:1.0: FTDI USB Serial Device converter detected
[81288.264587] usb 1-2.4: Detected FT232RL
[81288.264617] usb 1-2.4: Number of endpoints 2
[81288.264648] usb 1-2.4: Endpoint 1 MaxPacketSize 64
[81288.264678] usb 1-2.4: Endpoint 2 MaxPacketSize 64
[81288.264709] usb 1-2.4: Setting MaxPacketSize 64
[81288.269409] usb 1-2.4: FTDI USB Serial Device converter now attached to 
ttyUSB0
[244500.186431] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
[244500.193756] usb 1-2: USB disconnect, device number 2
[244500.193756] usb 1-2.1: USB disconnect, device number 3
[244500.197296] usb 1-2: clear tt 4 (9081) error -19
[244500.206756] usb 1-2: clear tt 4 (9081) error -19
[244500.216766] smsc95xx 1-2.1:1.0: eth0: unregister 'smsc95xx' 
usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet
[244500.272369] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set 
baudrate
[244500.279937] ftdi_sio ttyUSB0: urb failed to clear flow control
[244501.531372] usb 1-2.4: USB disconnect, device number 8
[244501.532318] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now 
disconnected from ttyUSB0
[244501.532409] ftdi_sio 1-2.4:1.0: device disconnected

This board has 2 xbee devices talking to each other, on on a usb serial 
adapter and the other one is mapped on a native UART of the bbxm.

This is not the first I've this EMI error, but this is the first time I see 
the "usb 1-2: clear tt 4 (9081) error -19" part. 


Le mercredi 12 décembre 2012 12:19:26 UTC+1, Adrien Ferré a écrit :
>
> Hi
>
> We are facing this kind of issue on several beaglexm and panda es. We are 
> currently seting up a test case which is:
>
> Heavy network traffic:
>
> A ftp server on the LAN serving one file to all boards.
> All boards download the file, remove it, redownload it, ...
>
> Heavy usb traffic:
>
> We have to USB-Serial adapters wired together at 115200 with RTS/CTS 
> enabled and serving a file to each other simultaneously.
>
> We'll run the tests for a few days and I'll give the results here.
>
> OCS: do you have results to provide for your tests please?
>
> Le vendredi 24 février 2012 23:13:57 UTC+1, Paul Walmsley a écrit :
>>
>> cc'ing beagleboard list, Kevin
>>
>> Hi Richard,
>>
>> thanks for the patch.  A quick question for you or anyone else who is 
>> experiencing this problem.
>>
>> On Mon, 20 Feb 2012, Richard Watts wrote:
>>
>> > There is an erratum in DM3730 which results in the
>> > EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
>> > leads to USB PHY clock drift and once the clock has drifted far
>> > enough, the PHY's ULPI interface stops responding and USB
>> > drops out. This is manifested on a Beagle xM by having the attached
>> > SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
>> > or similar.
>> > 
>> > The fix is to carefully adjust your DPLL5 settings so as to
>> > keep the PHY clock as close as possible to 120MHz over the long
>> > term; TI SPRZ319e gives a table of such settings and this patch
>> > applies that table to systems with a 13MHz or a 26MHz clock,
>> > thus fixing the issue (inasfar as it can be fixed) on Beagle xM
>> > and Overo Firestorm.
>> > 
>> > Signed-off-by: Richard Watts <r...-XQiHveOWqdgqdlJmJB21zg@public.gmane.org>
>>
>> Funny, I just had a conversation with Kevin Hilman about needing to put 
>> the DPLL rate rounding code back in for the OPP tables.  This looks like 
>> another reason why...
>>
>> Could you, or anyone else who is experiencing this problem on a board 
>> with 
>> a 26MHz oscillator try a quick test for me?  I'm a little curious about 
>> the (M, N) of (443, 12) that SPRZ319E is recommending.  Could you see if 
>> your USB problems are also solved by using (480, 13) ?
>>
>> ...
>>
>> Here's the rationale.  Walking through the estimates here based on 
>> SPRZ319E, (443, 12) results in a frequency error of -166,667 Hz at the 
>> VCO 
>> output.  This is 174 ppm below the desired target rate of 960MHz.  But 
>> (480, 13) results in no frequency error.
>>
>> The downside of using (480, 13) is that the PLL update interval increases 
>> from 461 ns to 500 ns (+9%).  But if the long-term drift of the DPLL is 
>> downward, then starting at a -174 ppm error has removed 35% of the total 
>> margin (+/- 500 ppm).  This might be too naïve, but a downward drift, 
>> seems likely given that gate delay increases as temperature increases.
>>
>> Mainline is currently using (120, 13) which results in a VCO output 
>> frequency of 240MHz -- this presumably results in increased phase noise 
>> compared to (443, 12) and (480, 13) per SPRZ319E.  
>>
>>
>> - Paul
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss



[-- Attachment #2: Type: text/html, Size: 6386 bytes --]

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Paul Walmsley]

Hi Adrien

On Thu, 20 Dec 2012, Adrien Ferré wrote:

> The tests have been running for 6 days now and we had only one failing BBxm
> 
> There are five boards:
> 
> 2 panda: high network + usb traffic
> 3 bbxm: high network + usb traffic

Nice; is that with (443, 12) or (480, 13) ?


- Paul

-- 
For more options, visit http://beagleboard.org/discuss

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 460 bytes --]

On Thu, 20 Dec 2012, Paul Walmsley wrote:

> On Thu, 20 Dec 2012, Adrien Ferré wrote:
> 
> > The tests have been running for 6 days now and we had only one failing BBxm
> > 
> > There are five boards:
> > 
> > 2 panda: high network + usb traffic
> > 3 bbxm: high network + usb traffic
> 
> Nice; is that with (443, 12) or (480, 13) ?

Adrien responded to me in private E-mail saying that this was without any 
changes at all.  Hmm...


- Paul

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Adrien Ferré]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

Hi,

Sry about the private answer, I thought that using emails would publish the 
content of the email here.

Nothing new has come up during the tests. It has been 14 days now and 
everything seems to run smoothly. I am starting to suspect that temperature 
is an issue. The next step would be to put the tested boards in some kind 
of enclosure and run them again for a couple of weeks.

Le vendredi 21 décembre 2012 00:06:48 UTC+1, Paul Walmsley a écrit :
>
> On Thu, 20 Dec 2012, Paul Walmsley wrote: 
>
> > On Thu, 20 Dec 2012, Adrien Ferré wrote: 
> > 
> > > The tests have been running for 6 days now and we had only one failing 
> BBxm 
> > > 
> > > There are five boards: 
> > > 
> > > 2 panda: high network + usb traffic 
> > > 3 bbxm: high network + usb traffic 
> > 
> > Nice; is that with (443, 12) or (480, 13) ? 
>
> Adrien responded to me in private E-mail saying that this was without any 
> changes at all.  Hmm... 
>
>
> - Paul

-- 
For more options, visit http://beagleboard.org/discuss



[-- Attachment #2: Type: text/html, Size: 1382 bytes --]

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Cliff Brake]

On Mon, Feb 20, 2012 at 12:58 PM, Richard Watts <rrw@kynesim.co.uk> wrote:
>
> There is an erratum in DM3730 which results in the
> EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
> leads to USB PHY clock drift and once the clock has drifted far
> enough, the PHY's ULPI interface stops responding and USB
> drops out. This is manifested on a Beagle xM by having the attached
> SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
> or similar.
>
> The fix is to carefully adjust your DPLL5 settings so as to
> keep the PHY clock as close as possible to 120MHz over the long
> term; TI SPRZ319e gives a table of such settings and this patch
> applies that table to systems with a 13MHz or a 26MHz clock,
> thus fixing the issue (inasfar as it can be fixed) on Beagle xM
> and Overo Firestorm.
>
> Signed-off-by: Richard Watts <rrw@kynesim.co.uk>

Has any more testing been done with this?  We're running into a
situation where the USB subsystem crashes in a beagleboard xM after
running for a couple hours to a day.  A USB camera is running
continuously during this time.  The error message typically something
like:

[ 2817.415710] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
[ 2817.422607] usb 1-2: USB disconnect, device number 2
[ 2817.427886] usb 1-2.1: USB disconnect, device number 3
[ 2817.441986] usb 1-2.4: USB disconnect, device number 4
[ 2817.450134] usb 1-2.5: USB disconnect, device number 5

Thanks,
Cliff

-- 
=================
http://bec-systems.com

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Paul Walmsley]

Hi Cliff,

On Tue, 12 Mar 2013, Cliff Brake wrote:

> On Mon, Feb 20, 2012 at 12:58 PM, Richard Watts <rrw@kynesim.co.uk> wrote:
> >
> > There is an erratum in DM3730 which results in the
> > EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
> > leads to USB PHY clock drift and once the clock has drifted far
> > enough, the PHY's ULPI interface stops responding and USB
> > drops out. This is manifested on a Beagle xM by having the attached
> > SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
> > or similar.
> >
> > The fix is to carefully adjust your DPLL5 settings so as to
> > keep the PHY clock as close as possible to 120MHz over the long
> > term; TI SPRZ319e gives a table of such settings and this patch
> > applies that table to systems with a 13MHz or a 26MHz clock,
> > thus fixing the issue (inasfar as it can be fixed) on Beagle xM
> > and Overo Firestorm.
> >
> > Signed-off-by: Richard Watts <rrw@kynesim.co.uk>
> 
> Has any more testing been done with this?  We're running into a
> situation where the USB subsystem crashes in a beagleboard xM after
> running for a couple hours to a day.  A USB camera is running
> continuously during this time.  The error message typically something
> like:
> 
> [ 2817.415710] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
> [ 2817.422607] usb 1-2: USB disconnect, device number 2
> [ 2817.427886] usb 1-2.1: USB disconnect, device number 3
> [ 2817.441986] usb 1-2.4: USB disconnect, device number 4
> [ 2817.450134] usb 1-2.5: USB disconnect, device number 5

Are you in a position to test whether the patch works for you?

I'd still like to find someone whose USB problem is fixed by the patch and 
is willing to try a slight modification of it before applying...


- Paul

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Cliff Brake]

On Tue, Mar 12, 2013 at 10:57 AM, Paul Walmsley <paul@pwsan.com> wrote:

> Are you in a position to test whether the patch works for you?
>
> I'd still like to find someone whose USB problem is fixed by the patch and
> is willing to try a slight modification of it before applying...

Yes, I'm in a position to test.  Please send me any updates as I'm
working on getting the patch applied now.  We have been running a
fairly old kernel (2.6.39), but could run any version you recommend.

Thanks,
Cliff

-- 
=================
http://bec-systems.com

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Robert Nelson]

>> Has any more testing been done with this?  We're running into a
>> situation where the USB subsystem crashes in a beagleboard xM after
>> running for a couple hours to a day.  A USB camera is running
>> continuously during this time.  The error message typically something
>> like:
>>
>> [ 2817.415710] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
>> [ 2817.422607] usb 1-2: USB disconnect, device number 2
>> [ 2817.427886] usb 1-2.1: USB disconnect, device number 3
>> [ 2817.441986] usb 1-2.4: USB disconnect, device number 4
>> [ 2817.450134] usb 1-2.5: USB disconnect, device number 5
>
> Are you in a position to test whether the patch works for you?
>
> I'd still like to find someone whose USB problem is fixed by the patch and
> is willing to try a slight modification of it before applying...

HI Paul,

I just recently traded with one of our customers for his "bad" xM.  If
you have something, I'm always running on mainline kernel's..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Cliff Brake]

On Tue, Mar 12, 2013 at 11:33 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
> On Tue, Mar 12, 2013 at 10:57 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
>> Are you in a position to test whether the patch works for you?
>>
>> I'd still like to find someone whose USB problem is fixed by the patch and
>> is willing to try a slight modification of it before applying...
>
> Yes, I'm in a position to test.  Please send me any updates as I'm
> working on getting the patch applied now.  We have been running a
> fairly old kernel (2.6.39), but could run any version you recommend.

This patch applied cleanly to the 2.6.39 tree I'm using, so I'm
running an overnight test with it now.  Will report back later.

Thanks,
Cliff

-- 
=================
http://bec-systems.com

Re: [PATCH 1/1] Fix sprz319 erratum 2.1

[Cliff Brake]

On Tue, Mar 12, 2013 at 2:52 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
> On Tue, Mar 12, 2013 at 11:33 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
>> On Tue, Mar 12, 2013 at 10:57 AM, Paul Walmsley <paul@pwsan.com> wrote:
>>
>>> Are you in a position to test whether the patch works for you?
>>>
>>> I'd still like to find someone whose USB problem is fixed by the patch and
>>> is willing to try a slight modification of it before applying...
>>
>> Yes, I'm in a position to test.  Please send me any updates as I'm
>> working on getting the patch applied now.  We have been running a
>> fairly old kernel (2.6.39), but could run any version you recommend.
>
> This patch applied cleanly to the 2.6.39 tree I'm using, so I'm
> running an overnight test with it now.  Will report back later.

It ran overnight without any USB problems.  Continuing to test ...

Thanks,
Cliff

-- 
=================
http://bec-systems.com