On Fri, 13 May 2011 18:39:34 +0800 jekyll <[email protected]> wrote:
> 2011/5/13 Alan Cox <[email protected]> > > > On Thu, 12 May 2011 21:21:48 +0800 > > Jekyll Lai <[email protected]> wrote: > > > > > Fixed the system crash when inserting or removing otg cable. > > > > Can you explain what the crash looks like and why it crashes ? > > > > No message from debug board or LCD. This system is frozen immediately. Most likely the crash is the result of handling irq from the port change event without resume device to D0. You can confirm that if you see the red iErr LED lit up a few minutes after the crash. i have been trying to fix this but so far haven't found a good solution, the complexity comes from irq sharing, unbalanced rpm calls as a result of unexpected hw states. I have described the issues i found in bug id 8188. Here is the description i put in. Please let me know if you see different results. "There are a few issues with OTG runtime PM. 1. at start up, if nothing plugged in the otg controller reports wrong status of b_session_valid. I have been working with SCU FW to debug this. The impact of this bug (hw) is that OTG state machine will start in the wrong initial state. 2. when b-cable is plugged in, suspend request interrupt is received. so instead of having a balanced resume-suspend calls, it will produce more suspend than resume which mess up the current runtime pm code. driver need to be changed keep rpm in balance. 3. when device is in suspend and d0i3 is set by pmu driver, interrupt is still allowed. Device must be resumed to d0 before handling irq. otg, udc, ehci handlers shall all process the resume in that they share the same irq and no ordering can be predicted in the current way of irq sharing. We also need to prevent threshing d0-d3 states to reduce overhead of checking rpm resume/suspend on every irq." _______________________________________________ MeeGo-kernel mailing list [email protected] http://lists.meego.com/listinfo/meego-kernel
