[U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.

[Roger Quadros <rogerq@ti.com>]

Hi,

On 08/20/2013 11:50 AM, Andreas Naumann wrote:
> Hi,
> 
> Am 16.08.2013 17:30, schrieb Robert Nelson:
>> On Fri, Aug 16, 2013 at 10:07 AM, Robert Nelson <robertcnelson@gmail.com> wrote:
>>> On Fri, Aug 16, 2013 at 9:34 AM, Peter A. Bigot <pab@pabigot.com> wrote:
>>>> On 08/16/2013 08:38 AM, Tom Rini wrote:
>>>>>
>>>>> On Wed, Aug 14, 2013 at 09:53:16PM -0500, Peter A. Bigot wrote:
>>>>>>
>>>>>> On 07/09/2013 02:43 AM, Naumann Andreas wrote:
>>>>>>>
>>>>>>> In chapter 'Advisory 2.1 USB Host Clock Drift Causes USB Spec
>>>>>>> Non-compliance in Certain Configurations' of the TI Errata it is recommended
>>>>>>> to use certain div/mult values for the DPLL5 clock setup.
>>>>>>> So far u-boot used the old 34xx values, so I added the errata
>>>>>>> recommended values specificly for 36xx init only.
>>>>>>> Also, the FSEL registers exist no longer, so removed them from init.
>>>>>>>
>>>>>>> Tested this on a AM3703 board with 19.2MHz oscillator, which previously
>>>>>>> couldnt lock the dpll5 (kernel complained). As a consequence the EHCI USB
>>>>>>> port wasnt usable in U-Boot and kernel. With this patch, kernel panics
>>>>>>> disappear and USB working fine in u-boot and kernel.
>>>>>>>
>>>>>>> Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>
>>>>>>
>>>>>> While this patch works with Linux that has been patched for this
>>>>>> erratum, it will cause problems with some unpatched versions of
>>>>>> Linux.
>>>>>
>>>>> Right.  So Linux also needs to be patched for the erratum.
>>>>
>>>>
>>>> Yes.  My point was that if you update u-boot alone, then try to use it to
>>>> boot an unpatched Linux that assumes CM_CLKSEL5_PLL has its power-on value,
>>>> USB will not work.
> 
> Oh, I was not aware of that. But indeed i use a patched 3.1 kernel, see below.
> Some info on the history: In our design (19.2MHz crystal) we could clearly see the errata problem of high jitter on the 60MHz USB clock when (re-)booting a board that was already warmed up.
> Back then I applied a slightly extended kernel patch (see below) that I found on some kernel list. This reproducably did solve the problem with the jitter. We verified this with a high quality oscilloscope and numerous powercycles at different temperatures. The U-Boot in use was 2010.09 and some old X-Loader, both of which dont touch the PLL4/5 stuff.
> 
> Introducing the current U-Boot (to make use of SPL) brought up above described problems with the clock, probably due to setting the lock mode active. Hence this patch for DM37xx.
> 

What are the symptoms you see when this issue triggers?

What is the test case to trigger the error? Is it just running any USB I/O for
long enough time?

I have a beagle-xm (DM3730 ES1.2) with me and would like to reproduce the error.

cheers,
-roger