On Fri, Aug 12, 2011 at 10:04 AM, Alan Stern <st...@rowland.harvard.edu> wrote:
>
> On Fri, 12 Aug 2011, Pandita, Vikram wrote:
>
> > On Fri, Aug 12, 2011 at 8:50 AM, Alan Stern <st...@rowland.harvard.edu>
> > wrote:
> > > On Fri, 12 Aug 2011, Vikram Pandita wrote:
> > >
> > >> From: Vikram Pandita <vikram.pand...@ti.com>
> > >>
> > >> 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.
> > >
> > > 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
