Paul Walmsley wrote: > On Mon, 21 Jun 2010, Paul Walmsley wrote: > > 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. > > Will requeue this for 2.6.36 merge window since it is not a regression, > and it seems that Linus wants regression fixes for the -rc series... > I received a bug-report last Friday from some user of the recently-merged ohci-omap3 driver about a data-abort caused at driver load. This patch fixes that issue. This wasn't known to me when I originally submitted the patch, but looks like this is a problem caused in a driver that went in in the last merge window. So maybe this patch can go in in the -rc series. ;) It's your call. I'm not particular. - Anand -- 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
