usb: ehci-msm-hsic: replace wakelock with wakeup source
In some cases of system suspend, it's possible a runtime resume
may be called on a device if it's already autosuspended (say, in
order to set a device- or port-specific feature, such as the remote
wakeup setting) just prior to putting it back into low power mode.
In this case, if the controller was also auto-suspended it will also
be temporarily runtime resumed by the fact that it is an ancestor to
said device.
The incoming wakelock re-implementation from Google based on wakeup
sources breaks this driver in the above scenario since now acquiring
a wakelock (which calls __pm_stay_awake) during runtime resume while
a simultaneous asynchronous suspend callback of another device is
called will cause it to abort the entire suspend attempt.
This prompts reconsideration of why a wakelock is needed in this
driver. One apparent use is to ensure this controller's runtime
suspend is called before system suspend is allowed. In other words,
we wish to guarantee the HSIC child devices are suspended before
suspending the controller. This can be done by checking that the root
hub device is suspended, else we can abort the suspend callback by
returning -EBUSY.
To handle the cases of interrupts happening during systemwide suspend
but after the controller was already suspended (and thus its runtime
PM disabled), call the pm_stay_awake() to denote a wakeup event. This
will cause the suspend to abort as well as block it from happening
until the interrupt can be serviced--after the controller resumes.
Change-Id: I4fab47c54f7d57065833d96261de08dcdd7238dc
Signed-off-by: Jack Pham <jackp@codeaurora.org>
1 file changed