On 06/17/2014 05:17 AM, Wang, Yu Y wrote:
>
> Hi All,
>
> I have one question about Linux xHCI driver. Need your help to introduce more backgrounds.
> About the S3 flow:
> 1, Freeze all user processes.
> 2, Freeze all kernel threads (including workqueue thread).
> 3, Trying to suspend all devices.
> 3.1, if pci device in RPM suspended, then try to resume it to D0. Call pm_runtime_resume API in prepare stage.
> 3.2, xhci_resume callback will call usb_hcd_resume_root_hub to queue two workqueue items to resume USB2&USB3 roothub devices.
> 3.3, call suspend callback of devices.
> 3.3.1, All suspend callback be called of hcd's children included roothub.
> 3.3.2, Finally, hcd_pci_suspend callback will be called.
>
> For above S3 enter flow. Due to workqueue thread were already frozen in step 2. So the two workqueue items can't be scheduled in step 3.2. But step 3.2 will set HCD_FLAG_WAKEUP_PENDING flag to hcd and shared_hcd which expecting clear in bus_resume which will not be executed in this scenario. It will cause step 3.3.2 return -EBUSY due to HCD_FLAG_WAKEUP_PENDING flag is set. Finally, S3 enter failed.
>
> As my debugging, I see sometimes, the HCD_FLAG_WAKEUP_PENDING flag will be clear in step 3.3.1 due to udev->do_remote_wakeup is not equal device_may_wakeup(&udev->dev) in choose_wakeup function.
>
> Is it by design behavior? Or it is just one lucky hit?
> Another question, step 3.2, why xhci_resume try to positive to resume its roothub devices?
>
Hi
This is a good question, I'm not that familiar with the internal details of pm framework or the usb core power management.
The powermanagemnt workqueue (pm_wq) which is used by the PM framework is used here as well to resume the root hub
by calling hcd_bus_resume() which clears WAKEUP_PENDING flags. I have a hard time believing this workqueue can't be scheduled in the middle of
PM transitions activity.
I think that it should be possible to suspend a device already in runtime suspend without resuming it first.
This would at least make sure the runtime resume won't cause the system suspend to fail.
The patch that adds roothub resume on controller resume explains the reasons why:
commit f69e3120df82391a0ee8118e0a156239a06b2afb
Author: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
Date: Thu Nov 3 11:37:10 2011 -0400
USB: XHCI: resume root hubs when the controller resumes
This patch (as1494) fixes a problem in xhci-hcd's resume routine.
When the controller is runtime-resumed, this can only mean that one of
the two root hubs has made a wakeup request and therefore needs to be
resumed as well. Rather than try to determine which root hub requires
attention (which might be difficult in the case where a new
non-SuperSpeed device has been plugged in), the patch simply resumes
both root hubs.
Without this change, there is a race: The controller might be put back
to sleep before it can activate its IRQ line, and the wakeup condition
might never get handled.
The patch also simplifies the logic in xhci_resume a little, combining
some repeated flag settings into a single pair of statements.
Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
CC: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
Cc: stable <stable@xxxxxxxxxxxxxxx>
Tested-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
I'm adding Alan Stern and the public usb list to this thread,
Alan in particular has far better insight in usb PM
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
