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 <[email protected]>
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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
