Hi Paul, Resurrecting an old thread :-) On Thursday 12 Jul 2012 15:19:37 Paul Walmsley wrote: > 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. I've been pinged by a customer today who wanted to know why this patch hasn't been merged, as it fixes the issue for them. Beside the obvious rebase, what would it take to get this upstream ? > > 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...@xxxxxxxxxxxxx> > > > > 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? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
