On Sat, 19 Jun 2010, Gadiyar, Anand wrote: > Gadiyar, Anand wrote: > > We need to wait on the IDLEST bit after the clocks are enabled > > before attempting to access any register. > > > > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait, > > while the USBTLL f-clock ops uses clkops_omap2_dflt. If the > > i-clock is enabled first, the clkops_omap2_dflt_wait is > > short-circuited as the companion f-clock is not enabled. > > This can cause a data abort if the IDLEST has not transitioned, > > and we try to access a USBTLL register. > > > > Since the USBTLL i-clock and f-clock could be enabled in any order, > > this is a bug. Fix it by changing the clkops for the f-clock. > > > > Signed-off-by: Anand Gadiyar <gadiyar@xxxxxx> It looks fine to me. I will queue it for a -rc branch. > Ping? Generally it is helpful if you have a patch for a subsystem that I maintain, to cc me directly. - Paul > > > > --- > > > > arch/arm/mach-omap2/clock3xxx_data.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c > > =================================================================== > > --- linux-omap-2.6.orig/arch/arm/mach-omap2/clock3xxx_data.c > > +++ linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c > > @@ -1484,7 +1484,7 @@ static struct clk ts_fck = { > > > > static struct clk usbtll_fck = { > > .name = "usbtll_fck", > > - .ops = &clkops_omap2_dflt, > > + .ops = &clkops_omap2_dflt_wait, > > .parent = &dpll5_m2_ck, > > .enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3), > > .enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT, > > -- > 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 > - Paul -- 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