Fix sprz319 erratum 2.1

PATCH In review Richard Watts 7 participants 15 messages Feb 20, 2012 – Mar 13, 2013 5 messages not in the archive

Subsystems (4)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP clock framework support

lore

Share & tools

lore

Richard Watts

author

2012-02-20 18:04 UTC #0 lore raw

PATCH 1/1 Fix sprz319 erratum 2.1

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 <[email protected]>

---

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(-)

arch/arm/mach-omap2/clkt_clksel.c +15 -0

index e25364d..e378fe7 100644
@@ -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

arch/arm/mach-omap2/clock.h +7 -0

index b8c2a68..5b149cd 100644
@@ -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);

arch/arm/mach-omap2/clock3xxx.c +57 -8

82 lines not on this page · raw message

arch/arm/mach-omap2/clock3xxx.h +1 -0

index 8bbeeaf..0ede513 100644
@@ -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);

arch/arm/mach-omap2/clock3xxx_data.c +1 -1

index d75e5f6..02f7676 100644
@@ -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,
 };

arch/arm/mach-omap2/dpll3xxx.c +1 -1

index fc56745..50ccee4 100644
@@ -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;

Signature · 1 line

1.7.5.4

Paul Walmsley

maintainer

2012-02-24 22:13 UTC #1 lore raw

cc'ing beagleboard list, Kevin

Hi Richard,

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

Quoted 8 lines · 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.

Quoted 8 lines

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 <[email protected]>

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

Paul Walmsley

maintainer

2012-07-12 21:19 UTC #2 lore raw

Hi,

Quoted 48 lines · Paul Walmsley

cc'ing beagleboard list, Kevin
Hi Richard,
thanks for the patch. A quick question for you or anyone else who is experiencing this problem.
Quoted 8 lines · 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.
Quoted 8 lines
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 <[email protected]>
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.

Quoted 3 lines

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

A message that is not in the archive (sent off-list or not yet received): alpine.DEB.2.00.1207121518240.25585-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org

OCS

2012-09-07 11:34 UTC #4 lore raw

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

Quoted 60 lines · Paul Walmsley

Hi,
Quoted 24 lines · Paul Walmsley
cc'ing beagleboard list, Kevin
Hi Richard,
thanks for the patch. A quick question for you or anyone else who is experiencing this problem.
Quoted 15 lines · 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.
Quoted 7 lines
Quoted 1 line
Signed-off-by Richard Watts <[email protected] <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
Quoted 8 lines
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
Quoted 4 lines
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
Quoted 8 lines
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.

Quoted 6 lines

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-/[email protected] Frequently asked questions: http://beagleboard.org/faq

A message that is not in the archive (sent off-list or not yet received): alpine.DEB.2.00.1202241419580.23504-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org

Adrien Ferré

2012-12-12 11:19 UTC #6 lore raw

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?

Quoted 57 lines · Paul Walmsley

cc'ing beagleboard list, Kevin
Hi Richard,
thanks for the patch. A quick question for you or anyone else who is experiencing this problem.
Quoted 8 lines · 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.
Quoted 8 lines
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 <[email protected] <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

Signature · 1 line

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

A message that is not in the archive (sent off-list or not yet received): 8f4f87ed-61f7-44ee-9c74-0f57e0f6a930-/[email protected]

Adrien Ferré

2012-12-20 14:51 UTC #8 lore raw

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.

Quoted 80 lines · Adrien Ferré

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?
Quoted 59 lines · Paul Walmsley
cc'ing beagleboard list, Kevin
Hi Richard,
thanks for the patch. A quick question for you or anyone else who is experiencing this problem.
Quoted 8 lines · 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.
Quoted 8 lines
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 <[email protected]>
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

Signature · 1 line

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

A message that is not in the archive (sent off-list or not yet received): d94a4cfd-538c-481c-aa8f-26a730739ac5-/[email protected]

Paul Walmsley

2012-12-20 15:34 UTC #10 lore raw

Hi Adrien

Quoted 6 lines · Adrien Ferré

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

Signature · 1 line

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

Paul Walmsley

maintainer

2012-12-20 23:06 UTC #11 lore raw

Quoted 10 lines · Paul Walmsley

Quoted 6 lines · Adrien Ferré
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

A message that is not in the archive (sent off-list or not yet received): alpine.DEB.2.00.1212202305510.20441-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org

Adrien Ferré

2012-12-28 10:34 UTC #13 lore raw

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.

Quoted 20 lines · Paul Walmsley

Quoted 3 lines · Paul Walmsley
Quoted 1 line · Adrien Ferré
The tests have been running for 6 days now and we had only one failing
BBxm
Quoted 7 lines
Quoted 5 lines
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

Signature · 1 line

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

Cliff Brake

2013-03-12 14:11 UTC #14 lore raw

In reply to Richard Watts

Quoted 9 lines · 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.

Quoted 8 lines

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 <[email protected]>

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

Signature · 2 lines

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

Paul Walmsley

maintainer

2013-03-12 14:57 UTC #15 lore raw

Hi Cliff,

Quoted 25 lines · Cliff Brake

Quoted 9 lines · 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.
Quoted 8 lines
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 <[email protected]>
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:

Quoted 5 lines

[ 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

Cliff Brake

2013-03-12 15:33 UTC #16 lore raw

Quoted 4 lines · Paul Walmsley

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

Signature · 2 lines

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

Cliff Brake

2013-03-12 18:52 UTC #17 lore raw

Quoted 10 lines · Cliff Brake

Quoted 4 lines · Paul Walmsley
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

Signature · 2 lines

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

Cliff Brake

2013-03-13 12:13 UTC #18 lore raw

Quoted 8 lines · Cliff Brake

Quoted 7 lines · Cliff Brake
Quoted 4 lines · Paul Walmsley
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...

Quoted 6 lines

Quoted 3 lines
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

Signature · 2 lines

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

Robert Nelson

2013-03-12 15:50 UTC #19 lore raw

In reply to Paul Walmsley

Quoted 12 lines

Quoted 11 lines
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

Quoted 4 lines

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,

Signature · 2 lines

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