* [U-Boot] [PATCH] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
@ 2013-07-09 7:43 Andreas Naumann
2013-08-15 2:53 ` [U-Boot] " Peter A. Bigot
2013-08-16 13:35 ` Tom Rini
0 siblings, 2 replies; 11+ messages in thread
From: Andreas Naumann @ 2013-07-09 7:43 UTC (permalink / raw)
To: u-boot
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>
---
arch/arm/cpu/armv7/omap3/clock.c | 20 +++++++++++++++++++-
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 18 ++++++++++++++++++
arch/arm/include/asm/arch-omap3/clocks_omap3.h | 22 ++++++++++++++++++++++
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap3/clock.c b/arch/arm/cpu/armv7/omap3/clock.c
index 81cc859..68833ba 100644
--- a/arch/arm/cpu/armv7/omap3/clock.c
+++ b/arch/arm/cpu/armv7/omap3/clock.c
@@ -491,6 +491,24 @@ static void dpll4_init_36xx(u32 sil_index, u32 clk_index)
wait_on_value(ST_PERIPH_CLK, 2, &prcm_base->idlest_ckgen, LDELAY);
}
+static void dpll5_init_36xx(u32 sil_index, u32 clk_index)
+{
+ struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
+ dpll_param *ptr = (dpll_param *) get_36x_per2_dpll_param();
+
+ /* Moving it to the right sysclk base */
+ ptr = ptr + clk_index;
+
+ /* PER2 DPLL (DPLL5) */
+ sr32(&prcm_base->clken2_pll, 0, 3, PLL_STOP);
+ wait_on_value(1, 0, &prcm_base->idlest2_ckgen, LDELAY);
+ sr32(&prcm_base->clksel5_pll, 0, 5, ptr->m2); /* set M2 (usbtll_fck) */
+ sr32(&prcm_base->clksel4_pll, 8, 11, ptr->m); /* set m (11-bit multiplier) */
+ sr32(&prcm_base->clksel4_pll, 0, 7, ptr->n); /* set n (7-bit divider)*/
+ sr32(&prcm_base->clken2_pll, 0, 3, PLL_LOCK); /* lock mode */
+ wait_on_value(1, 1, &prcm_base->idlest2_ckgen, LDELAY);
+}
+
static void mpu_init_36xx(u32 sil_index, u32 clk_index)
{
struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
@@ -595,7 +613,7 @@ void prcm_init(void)
dpll3_init_36xx(0, clk_index);
dpll4_init_36xx(0, clk_index);
- dpll5_init_34xx(0, clk_index);
+ dpll5_init_36xx(0, clk_index);
iva_init_36xx(0, clk_index);
mpu_init_36xx(0, clk_index);
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index eacfef8..66a1b48 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -480,6 +480,19 @@ per_36x_dpll_param:
.word 26000, 432, 12, 9, 16, 9, 4, 3, 1
.word 38400, 360, 15, 9, 16, 5, 4, 3, 1
+per2_36x_dpll_param:
+/* 12MHz */
+.word PER2_36XX_M_12, PER2_36XX_N_12, 0, PER2_36XX_M2_12
+/* 13MHz */
+.word PER2_36XX_M_13, PER2_36XX_N_13, 0, PER2_36XX_M2_13
+/* 19.2MHz */
+.word PER2_36XX_M_19P2, PER2_36XX_N_19P2, 0, PER2_36XX_M2_19P2
+/* 26MHz */
+.word PER2_36XX_M_26, PER2_36XX_N_26, 0, PER2_36XX_M2_26
+/* 38.4MHz */
+.word PER2_36XX_M_38P4, PER2_36XX_N_38P4, 0, PER2_36XX_M2_38P4
+
+
ENTRY(get_36x_mpu_dpll_param)
adr r0, mpu_36x_dpll_param
mov pc, lr
@@ -499,3 +512,8 @@ ENTRY(get_36x_per_dpll_param)
adr r0, per_36x_dpll_param
mov pc, lr
ENDPROC(get_36x_per_dpll_param)
+
+ENTRY(get_36x_per2_dpll_param)
+ adr r0, per2_36x_dpll_param
+ mov pc, lr
+ENDPROC(get_36x_per2_dpll_param)
diff --git a/arch/arm/include/asm/arch-omap3/clocks_omap3.h b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
index 5925ac4..59e61e8 100644
--- a/arch/arm/include/asm/arch-omap3/clocks_omap3.h
+++ b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
@@ -336,4 +336,26 @@
#define PER_36XX_FSEL_38P4 0x07
#define PER_36XX_M2_38P4 0x09
+/* 36XX PER2 DPLL */
+
+#define PER2_36XX_M_12 0x50
+#define PER2_36XX_N_12 0x00
+#define PER2_36XX_M2_12 0x08
+
+#define PER2_36XX_M_13 0x1BB
+#define PER2_36XX_N_13 0x05
+#define PER2_36XX_M2_13 0x08
+
+#define PER2_36XX_M_19P2 0x32
+#define PER2_36XX_N_19P2 0x00
+#define PER2_36XX_M2_19P2 0x08
+
+#define PER2_36XX_M_26 0x1BB
+#define PER2_36XX_N_26 0x0B
+#define PER2_36XX_M2_26 0x08
+
+#define PER2_36XX_M_38P4 0x19
+#define PER2_36XX_N_38P4 0x00
+#define PER2_36XX_M2_38P4 0x08
+
#endif /* endif _CLOCKS_OMAP3_H_ */
--
1.8.3.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-07-09 7:43 [U-Boot] [PATCH] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e Andreas Naumann
@ 2013-08-15 2:53 ` Peter A. Bigot
2013-08-16 13:38 ` Tom Rini
2013-08-16 13:35 ` Tom Rini
1 sibling, 1 reply; 11+ messages in thread
From: Peter A. Bigot @ 2013-08-15 2:53 UTC (permalink / raw)
To: u-boot
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.
In particular, this patch sets CM_CLKSEL4_PLL to generate (nearly)
960MHz, and CM_CLKSEL5_PLL to divide by 8 to produce the required
120MHz, as recommended by sprz318e advisory 2.1.
Version 3.5 of Linux, and possibly others, configure CM_CLKSEL4_PLL
(named "dpll5_ck") to generate 120MHz and leaves CM_CLKSEL5_PLL
unmodified since its clock (named "dpll5_m2_ck") does not support set
rate. If u-boot has configured a divisor of 8, the result is that the
actual clock speed is 15MHz and USB does not work.
Not sure how this ought to be resolved; in my case I'm going to skip the
u-boot patch and just use the Linux patch.
Peter
>
> ---
> arch/arm/cpu/armv7/omap3/clock.c | 20 +++++++++++++++++++-
> arch/arm/cpu/armv7/omap3/lowlevel_init.S | 18 ++++++++++++++++++
> arch/arm/include/asm/arch-omap3/clocks_omap3.h | 22 ++++++++++++++++++++++
> 3 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/omap3/clock.c b/arch/arm/cpu/armv7/omap3/clock.c
> index 81cc859..68833ba 100644
> --- a/arch/arm/cpu/armv7/omap3/clock.c
> +++ b/arch/arm/cpu/armv7/omap3/clock.c
> @@ -491,6 +491,24 @@ static void dpll4_init_36xx(u32 sil_index, u32 clk_index)
> wait_on_value(ST_PERIPH_CLK, 2, &prcm_base->idlest_ckgen, LDELAY);
> }
>
> +static void dpll5_init_36xx(u32 sil_index, u32 clk_index)
> +{
> + struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
> + dpll_param *ptr = (dpll_param *) get_36x_per2_dpll_param();
> +
> + /* Moving it to the right sysclk base */
> + ptr = ptr + clk_index;
> +
> + /* PER2 DPLL (DPLL5) */
> + sr32(&prcm_base->clken2_pll, 0, 3, PLL_STOP);
> + wait_on_value(1, 0, &prcm_base->idlest2_ckgen, LDELAY);
> + sr32(&prcm_base->clksel5_pll, 0, 5, ptr->m2); /* set M2 (usbtll_fck) */
> + sr32(&prcm_base->clksel4_pll, 8, 11, ptr->m); /* set m (11-bit multiplier) */
> + sr32(&prcm_base->clksel4_pll, 0, 7, ptr->n); /* set n (7-bit divider)*/
> + sr32(&prcm_base->clken2_pll, 0, 3, PLL_LOCK); /* lock mode */
> + wait_on_value(1, 1, &prcm_base->idlest2_ckgen, LDELAY);
> +}
> +
> static void mpu_init_36xx(u32 sil_index, u32 clk_index)
> {
> struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
> @@ -595,7 +613,7 @@ void prcm_init(void)
>
> dpll3_init_36xx(0, clk_index);
> dpll4_init_36xx(0, clk_index);
> - dpll5_init_34xx(0, clk_index);
> + dpll5_init_36xx(0, clk_index);
> iva_init_36xx(0, clk_index);
> mpu_init_36xx(0, clk_index);
>
> diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
> index eacfef8..66a1b48 100644
> --- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
> +++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
> @@ -480,6 +480,19 @@ per_36x_dpll_param:
> .word 26000, 432, 12, 9, 16, 9, 4, 3, 1
> .word 38400, 360, 15, 9, 16, 5, 4, 3, 1
>
> +per2_36x_dpll_param:
> +/* 12MHz */
> +.word PER2_36XX_M_12, PER2_36XX_N_12, 0, PER2_36XX_M2_12
> +/* 13MHz */
> +.word PER2_36XX_M_13, PER2_36XX_N_13, 0, PER2_36XX_M2_13
> +/* 19.2MHz */
> +.word PER2_36XX_M_19P2, PER2_36XX_N_19P2, 0, PER2_36XX_M2_19P2
> +/* 26MHz */
> +.word PER2_36XX_M_26, PER2_36XX_N_26, 0, PER2_36XX_M2_26
> +/* 38.4MHz */
> +.word PER2_36XX_M_38P4, PER2_36XX_N_38P4, 0, PER2_36XX_M2_38P4
> +
> +
> ENTRY(get_36x_mpu_dpll_param)
> adr r0, mpu_36x_dpll_param
> mov pc, lr
> @@ -499,3 +512,8 @@ ENTRY(get_36x_per_dpll_param)
> adr r0, per_36x_dpll_param
> mov pc, lr
> ENDPROC(get_36x_per_dpll_param)
> +
> +ENTRY(get_36x_per2_dpll_param)
> + adr r0, per2_36x_dpll_param
> + mov pc, lr
> +ENDPROC(get_36x_per2_dpll_param)
> diff --git a/arch/arm/include/asm/arch-omap3/clocks_omap3.h b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
> index 5925ac4..59e61e8 100644
> --- a/arch/arm/include/asm/arch-omap3/clocks_omap3.h
> +++ b/arch/arm/include/asm/arch-omap3/clocks_omap3.h
> @@ -336,4 +336,26 @@
> #define PER_36XX_FSEL_38P4 0x07
> #define PER_36XX_M2_38P4 0x09
>
> +/* 36XX PER2 DPLL */
> +
> +#define PER2_36XX_M_12 0x50
> +#define PER2_36XX_N_12 0x00
> +#define PER2_36XX_M2_12 0x08
> +
> +#define PER2_36XX_M_13 0x1BB
> +#define PER2_36XX_N_13 0x05
> +#define PER2_36XX_M2_13 0x08
> +
> +#define PER2_36XX_M_19P2 0x32
> +#define PER2_36XX_N_19P2 0x00
> +#define PER2_36XX_M2_19P2 0x08
> +
> +#define PER2_36XX_M_26 0x1BB
> +#define PER2_36XX_N_26 0x0B
> +#define PER2_36XX_M2_26 0x08
> +
> +#define PER2_36XX_M_38P4 0x19
> +#define PER2_36XX_N_38P4 0x00
> +#define PER2_36XX_M2_38P4 0x08
> +
> #endif /* endif _CLOCKS_OMAP3_H_ */
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-07-09 7:43 [U-Boot] [PATCH] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e Andreas Naumann
2013-08-15 2:53 ` [U-Boot] " Peter A. Bigot
@ 2013-08-16 13:35 ` Tom Rini
1 sibling, 0 replies; 11+ messages in thread
From: Tom Rini @ 2013-08-16 13:35 UTC (permalink / raw)
To: u-boot
On Tue, Jul 09, 2013 at 09:43:17AM +0200, 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>
Applied to u-boot-ti/master with a prototype added to
<asm/arch-omap3/clock.h> to avoid a warning.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130816/6595c3bd/attachment.pgp>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-15 2:53 ` [U-Boot] " Peter A. Bigot
@ 2013-08-16 13:38 ` Tom Rini
2013-08-16 14:34 ` Peter A. Bigot
0 siblings, 1 reply; 11+ messages in thread
From: Tom Rini @ 2013-08-16 13:38 UTC (permalink / raw)
To: u-boot
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130816/d2950a69/attachment.pgp>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-16 13:38 ` Tom Rini
@ 2013-08-16 14:34 ` Peter A. Bigot
2013-08-16 15:07 ` Robert Nelson
0 siblings, 1 reply; 11+ messages in thread
From: Peter A. Bigot @ 2013-08-16 14:34 UTC (permalink / raw)
To: u-boot
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.
I think it's dangerous to assume that the mixture of an unpatched Linux
with a patched u-boot will never occur, and the cause of the failure
that results is pretty subtle. So whatever gets merged would be safer
if it restored the default setting of CM_CLKSEL5_PLL prior to handing
off control to Linux.
Peter
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-16 14:34 ` Peter A. Bigot
@ 2013-08-16 15:07 ` Robert Nelson
2013-08-16 15:30 ` Robert Nelson
0 siblings, 1 reply; 11+ messages in thread
From: Robert Nelson @ 2013-08-16 15:07 UTC (permalink / raw)
To: u-boot
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.
>
> I think it's dangerous to assume that the mixture of an unpatched Linux with
> a patched u-boot will never occur, and the cause of the failure that results
> is pretty subtle. So whatever gets merged would be safer if it restored the
> default setting of CM_CLKSEL5_PLL prior to handing off control to Linux.
Agree, we should not apply this, till we also have an 'approved' patch
for mainline linux posted. Right now we have a set of kernel hacks,
but no agreed on method as the kernel maintainer did not have a board
that suffered from the errata..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-16 15:07 ` Robert Nelson
@ 2013-08-16 15:30 ` Robert Nelson
2013-08-20 8:50 ` Andreas Naumann
0 siblings, 1 reply; 11+ messages in thread
From: Robert Nelson @ 2013-08-16 15:30 UTC (permalink / raw)
To: u-boot
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.
>>
>> I think it's dangerous to assume that the mixture of an unpatched Linux with
>> a patched u-boot will never occur, and the cause of the failure that results
>> is pretty subtle. So whatever gets merged would be safer if it restored the
>> default setting of CM_CLKSEL5_PLL prior to handing off control to Linux.
>
> Agree, we should not apply this, till we also have an 'approved' patch
> for mainline linux posted. Right now we have a set of kernel hacks,
> but no agreed on method as the kernel maintainer did not have a board
> that suffered from the errata..
btw: here's a version that seems to work on v3.11-rc5:
https://raw.github.com/RobertCNelson/armv7-multiplatform/v3.11.x/patches/omap_sprz319_erratum_v2.1/0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-16 15:30 ` Robert Nelson
@ 2013-08-20 8:50 ` Andreas Naumann
2013-08-20 9:45 ` Roger Quadros
0 siblings, 1 reply; 11+ messages in thread
From: Andreas Naumann @ 2013-08-20 8:50 UTC (permalink / raw)
To: u-boot
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.
>>>
>>> I think it's dangerous to assume that the mixture of an unpatched Linux with
>>> a patched u-boot will never occur, and the cause of the failure that results
>>> is pretty subtle. So whatever gets merged would be safer if it restored the
>>> default setting of CM_CLKSEL5_PLL prior to handing off control to Linux.
>>
>> Agree, we should not apply this, till we also have an 'approved' patch
>> for mainline linux posted. Right now we have a set of kernel hacks,
>> but no agreed on method as the kernel maintainer did not have a board
>> that suffered from the errata..
Unfortunately I dont find the origin of the kernel patch anymore, can
somebody point me in the right direction? Otherwise I could open a new
post on the linux-omap list. What do you think?
>
> btw: here's a version that seems to work on v3.11-rc5:
>
> https://raw.github.com/RobertCNelson/armv7-multiplatform/v3.11.x/patches/omap_sprz319_erratum_v2.1/0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch
>
Here my applied kernel patch. I had it working both on kernel 3.1 as
well as 3.4:
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 48ac568..3d2c899 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);
@@ -84,6 +90,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..97d4192 100644
--- a/arch/arm/mach-omap2/clock3xxx.c
+++ b/arch/arm/mach-omap2/clock3xxx.c
@@ -40,6 +40,63 @@
/* 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 },
+ { 12000000, 80, 0+1, 8 },
+ { 19200000, 50, 0+1, 8 },
+ { 26000000, 443+1, 11+1, 8 },
+ { 38400000, 25, 0+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 +116,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 b9b8446..33f9853 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 f77022b..1909cd0 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;
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-20 8:50 ` Andreas Naumann
@ 2013-08-20 9:45 ` Roger Quadros
2013-08-20 10:15 ` Andreas Naumann
0 siblings, 1 reply; 11+ messages in thread
From: Roger Quadros @ 2013-08-20 9:45 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-20 9:45 ` Roger Quadros
@ 2013-08-20 10:15 ` Andreas Naumann
2013-08-20 12:57 ` Robert Nelson
0 siblings, 1 reply; 11+ messages in thread
From: Andreas Naumann @ 2013-08-20 10:15 UTC (permalink / raw)
To: u-boot
Hi Roger,
>
> What are the symptoms you see when this issue triggers?
The symptoms are erroneous USB transaction, seen with a USB port
analyzer. These only sometimes (not always) stall the USB communication,
e.g. a USB mass storage device cant be read any longer.
>
> What is the test case to trigger the error? Is it just running any USB I/O for
> long enough time?
Our scenario to reproduce was rebooting a warmed up board (either let it
run for >5min or heat up in climate chamber).
However, the beagle probably uses a 26 MHz crystal oscillator (our board
uses 19.2MHz), so the PLL5 dividers may be set in a way that the problem
never occurs.
> I have a beagle-xm (DM3730 ES1.2) with me and would like to reproduce the error.
>
> cheers,
> -roger
>
regards,
Andreas
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
2013-08-20 10:15 ` Andreas Naumann
@ 2013-08-20 12:57 ` Robert Nelson
0 siblings, 0 replies; 11+ messages in thread
From: Robert Nelson @ 2013-08-20 12:57 UTC (permalink / raw)
To: u-boot
On Tue, Aug 20, 2013 at 5:15 AM, Andreas Naumann <dev@andin.de> wrote:
> Hi Roger,
>
>
>>
>> What are the symptoms you see when this issue triggers?
>
>
> The symptoms are erroneous USB transaction, seen with a USB port analyzer.
> These only sometimes (not always) stall the USB communication, e.g. a USB
> mass storage device cant be read any longer.
>
>
>>
>> What is the test case to trigger the error? Is it just running any USB I/O
>> for
>> long enough time?
>
>
> Our scenario to reproduce was rebooting a warmed up board (either let it run
> for >5min or heat up in climate chamber).
>
> However, the beagle probably uses a 26 MHz crystal oscillator (our board
> uses 19.2MHz), so the PLL5 dividers may be set in a way that the problem
> never occurs.
The xM uses a 26Mhz, but the errata still applies, as a number of
customer boards do show the issue..
http://www.ti.com/lit/er/sprz319e/sprz319e.pdf
page 113
>> I have a beagle-xm (DM3730 ES1.2) with me and would like to reproduce the
>> error.
Roger, this only seems to effect a small number of xM's, as it seems
to vary on pll drift. So if your xM is fine, i do have a spare xM C,
that pretty reliably shows the issue after transferring a large amount
of data over the usb port... I had traded a good xM with a customer
such that i could keep re-basing our out of tree dpll5 tweak..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-08-20 12:57 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-09 7:43 [U-Boot] [PATCH] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e Andreas Naumann
2013-08-15 2:53 ` [U-Boot] " Peter A. Bigot
2013-08-16 13:38 ` Tom Rini
2013-08-16 14:34 ` Peter A. Bigot
2013-08-16 15:07 ` Robert Nelson
2013-08-16 15:30 ` Robert Nelson
2013-08-20 8:50 ` Andreas Naumann
2013-08-20 9:45 ` Roger Quadros
2013-08-20 10:15 ` Andreas Naumann
2013-08-20 12:57 ` Robert Nelson
2013-08-16 13:35 ` Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.