Felipe On Fri, Aug 12, 2011 at 10:21 AM, Pandita, Vikram <[email protected]> wrote: > On Fri, Aug 12, 2011 at 10:04 AM, Alan Stern <[email protected]> > wrote: >> >> On Fri, 12 Aug 2011, Pandita, Vikram wrote: >> >> > On Fri, Aug 12, 2011 at 8:50 AM, Alan Stern <[email protected]> >> > wrote: >> > > On Fri, 12 Aug 2011, Vikram Pandita wrote: >> > > >> > >> From: Vikram Pandita <[email protected]> >> > >> >> > >> musb pm_runtime_get_sync call happens in intrrupt context on cable >> > >> attach case >> > >> That can result in re-enabling the interrupts and cause side affects. >> > >> >> > >> So move the code to a work queue.
Any chance you go to line this up for the merge window? >> > > >> > > Instead of creating your own, new work queue, just use the pre-existing >> > > PM work queue. In other words, replace pm_runtime_get_sync() with >> > > pm_runtime_get(). >> > >> > In this case it may not work, because immediately after a >> > pm_runtime_get_sync(), >> > we are going to access MUSB registers and xxx_sync() call ensures we >> > will not abort. >> >> I don't understand. Why not just access those registers from within >> the runtime_resume callback? > > I am not the runtime_pm expert, but as i understand, in this case: > > USB cable attach > Get Interrupt from Power IC (twl6030) > Interrupt handler calls notifier_call_chain - cable attach/detach > notification handler in MUSB code > Notification_handler does: > * enable clocks for musb register access > ** setup musb registers to start getting control ep0 interrupts > for usb enumeration > > * is the part were we need to do the clock enabling synchronously. > The runtime_resume() call-back today for musb does not have to do > anything with USB enumeration. > >> >> Alan Stern >> > -- 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
