Anand Gadiyar <gadi...@ti.com> writes:

> 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 <gadi...@ti.com>

Acked-by: Kevin Hilman <khil...@deeprootsystems.com>

> ---
>
>  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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to