| Message ID | 1252418056-5994-1-git-send-email-gadiyar@ti.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d3c59a8141676bc45f0341b470845b298d6a2a51 |
| Headers | show |
On Tue, 8 Sep 2009, Anand Gadiyar wrote: > From: Rajendra Nayak <rnayak@ti.com> > > OMAP3: Lock DPLL5 at boot > > Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and > USBTLL f-clock are the only users of this DPLL, and 120MHz is > is the only recommended rate for these clocks. > > With this patch, the 60 MHz ULPI clock is generated correctly. > > Tested on an OMAP3430 SDP. > > Signed-off-by: Rajendra Nayak <rnayak@ti.com> > Signed-off-by: Anand Gadiyar <gadiyar@ti.com> > --- > Incorporated all 3 comments by Paul and Benoit. Updated > $SUBJECT to reflect the change. Thanks for the changes, I will queue this in a for-next branch for .33. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul >-----Original Message----- >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Paul >Walmsley >Sent: Wednesday, September 09, 2009 10:43 AM >To: Gadiyar, Anand >Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; Cousson, Benoit >Subject: Re: [PATCH] OMAP3: Lock DPLL5 at boot > >On Tue, 8 Sep 2009, Anand Gadiyar wrote: > >> From: Rajendra Nayak <rnayak@ti.com> >> >> OMAP3: Lock DPLL5 at boot >> >> Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and >> USBTLL f-clock are the only users of this DPLL, and 120MHz is >> is the only recommended rate for these clocks. >> >> With this patch, the 60 MHz ULPI clock is generated correctly. >> >> Tested on an OMAP3430 SDP. >> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com> >> Signed-off-by: Anand Gadiyar <gadiyar@ti.com> >> --- >> Incorporated all 3 comments by Paul and Benoit. Updated >> $SUBJECT to reflect the change. > >Thanks for the changes, I will queue this in a for-next branch for .33. Is this for .33 or .32? > > >- Paul >-- >To unsubscribe from this list: send the line "unsubscribe linux-omap" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 9 Sep 2009, Pandita, Vikram wrote: > >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Paul > >Walmsley > >> $SUBJECT to reflect the change. > > > >Thanks for the changes, I will queue this in a for-next branch for .33. > > Is this for .33 or .32? I think it might be a little late for .32. If there is some crash or instability that this fixes, we could queue it up for .32-fixes ? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 9 Sep 2009, Paul Walmsley wrote: > On Wed, 9 Sep 2009, Pandita, Vikram wrote: > > > >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Paul > > >Walmsley > > >> $SUBJECT to reflect the change. > > > > > >Thanks for the changes, I will queue this in a for-next branch for .33. > > > > Is this for .33 or .32? > > I think it might be a little late for .32. If there is some crash or > instability that this fixes, we could queue it up for .32-fixes ? > Well, without this, there's no way the child clocks can be enabled correctly. Possibly it qualifies as a bug-fix in clock framework? Rajendra had created this patch quite a while ago and it has received sufficient testing on various codebases - I guess we just missed sending it out to l-o early enough. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 9 Sep 2009, Gadiyar, Anand wrote: > On Wed, 9 Sep 2009, Paul Walmsley wrote: > > On Wed, 9 Sep 2009, Pandita, Vikram wrote: > > > > > >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Paul > > > >Walmsley > > > >> $SUBJECT to reflect the change. > > > > > > > >Thanks for the changes, I will queue this in a for-next branch for .33. > > > > > > Is this for .33 or .32? > > > > I think it might be a little late for .32. If there is some crash or > > instability that this fixes, we could queue it up for .32-fixes ? > > Well, without this, there's no way the child clocks can be enabled correctly. OK. So is it the case that USBHOST/USBTLL/USIM won't work without this fix? If so then we'll queue it for .32-fixes. Since .32 is already at -rc9, I think it is too late for .32. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > >Thanks for the changes, I will queue this in a for-next branch for .33. > > > > > > > > Is this for .33 or .32? > > > > > > I think it might be a little late for .32. If there is some crash or > > > instability that this fixes, we could queue it up for .32-fixes ? > > > > Well, without this, there's no way the child clocks can be enabled correctly. > > OK. So is it the case that USBHOST/USBTLL/USIM won't work without this > fix? Yup. Not sure about USIM - will check. > > If so then we'll queue it for .32-fixes. Since .32 is already at -rc9, I > think it is too late for .32. > Would be nice. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c =================================================================== --- linux-omap-2.6.orig/arch/arm/mach-omap2/clock34xx.c +++ linux-omap-2.6/arch/arm/mach-omap2/clock34xx.c @@ -338,6 +338,13 @@ static struct omap_clk omap34xx_clks[] = */ #define SDRC_MPURATE_LOOPS 96 +/* + * DPLL5_FREQ_FOR_USBHOST: USBHOST and USBTLL are the only clocks + * that are sourced by DPLL5, and both of these require this clock + * to be at 120 MHz for proper operation. + */ +#define DPLL5_FREQ_FOR_USBHOST 120000000 + /** * omap3430es2_clk_ssi_find_idlest - return CM_IDLEST info for SSI * @clk: struct clk * being enabled @@ -1056,6 +1063,28 @@ void omap2_clk_prepare_for_reboot(void) #endif } +static void 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); + + /* Enable autoidle to allow it to enter low power bypass */ + omap3_dpll_allow_idle(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); + + clk_disable(dpll5_m2_clk); + clk_disable(dpll5_clk); + return; +} + /* REVISIT: Move this init stuff out into clock.c */ /* @@ -1148,6 +1177,12 @@ int __init omap2_clk_init(void) */ clk_enable_init_clocks(); + /* + * Lock DPLL5 and put it in autoidle. + */ + if (omap_rev() >= OMAP3430_REV_ES2_0) + omap3_clk_lock_dpll5(); + /* Avoid sleeping during omap2_clk_prepare_for_reboot() */ /* REVISIT: not yet ready for 343x */ #if 0