Re: [PATCH 1/1] Fix sprz319 erratum 2.1
On Tue, Mar 12, 2013 at 2:52 PM, Cliff Brake cliff.br...@gmail.com wrote: On Tue, Mar 12, 2013 at 11:33 AM, Cliff Brake cliff.br...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:57 AM, Paul Walmsley p...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix sprz319 erratum 2.1
On Mon, Feb 20, 2012 at 12:58 PM, Richard Watts r...@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 r...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix sprz319 erratum 2.1
Hi Cliff, On Tue, 12 Mar 2013, Cliff Brake wrote: On Mon, Feb 20, 2012 at 12:58 PM, Richard Watts r...@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 r...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix sprz319 erratum 2.1
On Tue, Mar 12, 2013 at 10:57 AM, Paul Walmsley p...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix sprz319 erratum 2.1
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/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix sprz319 erratum 2.1
On Tue, Mar 12, 2013 at 11:33 AM, Cliff Brake cliff.br...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:57 AM, Paul Walmsley p...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix sprz319 erratum 2.1
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
Re: [PATCH 1/1] Fix sprz319 erratum 2.1
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
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...@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
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...@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
[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 r...@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 ...
+ */
+ { 1300, 443+1, 5+1, 8 },
+ { 2600, 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;
+
