On Wed, 27 Feb 2013, Tony Camuso wrote:
> On 02/26/2013 11:11 AM, Alan Stern wrote:
> > On Tue, 26 Feb 2013, Tony Camuso wrote:
> >> Then should I continue to pursue relocating calls to init and delete
> >> the compliance mode recovery timer to xhci_bus_suspend/resume?
> >
> > I don't know. If you think the scheme will work then pursue it,
> > otherwise don't.
> >
> Alan,
>
> I was able to make the scheme work by adding the following
> immediately upon entering compliance_recovery_node_timer_init()
>
> if (timer_pending(&xhci->comp_mode_recovery_timer)) {
> xhci_dbg(xhci, "Compliance Mode Recovery Timer already
> active.\n");
> return;
> }
Okay.
> However ...
>
> I don't the bus level is the correct place to deal with this timer.
This is what I really can't answer. It all depends on when the
compliance-mode recovery timer needs to be running, and I don't
understand the details of how that timer is supposed to work.
> xhci_bus_suspend and xhci_bus_resume are called many times during boot,
> and not always serially. Consider the following snippets taken from
> boot with CONFIG_USB_DEBUG=y and CONFIG_USB_XHCI_HCD_DEBUGGING=y
> and printk's at the entry of xhci_bus_suspend and xhci_bus_resume.
>
> xhci_hcd 0000:08:00.0: Finished xhci_init
> xhci_hcd 0000:08:00.0: Compliance Mode Recovery Timer Initialized.
> :
> hub 3-0:1.0: hub_suspend
> usb usb3: bus auto-suspend, wakeup 1
> *** xhci_bus_suspend: pci:0000:08:00.0 usb-bus:4 slot_id:0 port:0
> xhci_hcd 0000:08:00.0: set port power, actual port 2 status = 0x2a0
> xhci_hcd 0000:08:00.0: Compliance Mode Recovery Timer Deleted!
> *** xhci_bus_suspend: completed normaly
> xhci_hcd 0000:08:00.0: xhci_hub_status_data: stopping port polling.
> :
> hub 4-0:1.0: hub_suspend
> usb usb4: bus auto-suspend, wakeup 1
> *** xhci_bus_suspend: pci:0000:08:00.0 usb-bus:4 slot_id:0 port:0
> xhci_hcd 0000:08:00.0: Compliance Mode Recovery Timer Deleted!
> *** xhci_bus_suspend: completed normaly
> xhci_hcd 0000:08:00.0: xhci_hub_status_data: stopping port polling.
This is normal. xhci_bus_suspend is called once for the legacy USB-2
root hub (usb3) and then again for the USB-3 root hub (usb4). I'd
guess that the compliance-mode recovery timer needs to be associated
with the USB-3 root hub only, but I don't know.
> :
> usb usb4: usb auto-resume
> *** xhci_bus_resume: pci:0000:08:00.0 usb-bus:4 slot_id:0 port:0
> xhci_hcd 0000:08:00.0: Compliance Mode Recovery Timer Initialized.
> *** xhci_bus_resume: completed normaly
> hub 4-0:1.0: hub_resume
> :
> usb usb4: usb auto-resume
> *** xhci_bus_resume: pci:0000:08:00.0 usb-bus:4 slot_id:0 port:0
> xhci_hcd 0000:08:00.0: Compliance Mode Recovery Timer Initialized.
> *** xhci_bus_resume: completed normaly
> hub 4-0:1.0: hub_resume
This seems wrong. You must have omitted a suspend between these two
resumes. The system does not resume a device that's already resumed.
> :
> hub 4-0:1.0: state 7 ports 4 chg 0000 evt 0000
> usb usb3: usb auto-resume
> *** xhci_bus_resume: pci:0000:08:00.0 usb-bus:4 slot_id:0 port:0
> *** xhci: Compliance Mode Recovery Timer already active.
> *** xhci_bus_resume: completed normaly
> hub 3-0:1.0: hub_resume
That's okay. The USB-2 root hub was suspended earlier, and now it is
resumed.
> :
> etc, etc,
>
> > As far as I know, xhci_bus_resume is never called without
> > xhci_bus_suspend being called first. Hence the timer should not be on
> > the list when xhci_bus_resume runs.
> >
> See above.
>
> >> Presently, the timer is added in xchi_init() and xhci_resume(). Our problem
> >> emerges when xhci_resume tries to add the timer after it has been restored
> >> by resuming from hibernate.
> >
> > In the new scheme, the timer should not be added by xhci_resume.
> >
> It wasn't, yet I still encountered the problem.
>
> As an aside, we may be able to leave the code as it is now and just add the
> code snippet at the top of this post.
>
> That solution introduces the least churn and solves the problem.
At this point I'd say to ask Sarah. She knows a lot more about the
big picture than I do.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
