RE: Remote wakeup timing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 12 Apr 2012, Chen Peter-B29397 wrote:

> > Good patch, Alan. Only one thing is that it needs a delay between
> > re-suspend, and send resume again. (Sorry, I can't find the detail
> > delay time between suspend and resume signal at usb2.0 spec).
> > 
> > I will test this patch, and give you a response.
> > 
> 
> I have some problems with patch, and the SOF isn't out after the second resume has finishes.
> I will go on debugging this problem next week.
> 
> I think this patch has some risks, and it needs both host and device's behavior to be correct
> after 2 times suspend/resume for every remote wakeup occurrence. Remote wakeup occurs:
> 
> - Device remote wakeup signal at both autosuspend/system suspend situation
> - Device connect/disconnect with/without HUB cases at both autosuspend/system suspend situation.
> 
> Esp for 3G/LTE modem cases, if it supports autosuspend at runtime, remote wakeup occurs very frequently. 

You're right.  And after thinking about this some more, I decided that 
your approach of turning on CMD_RUN during controller suspend is the 
easiest and best approach.

Two things: Your controller-resume routine should also call 
usb_hcd_resume_root_hub.  Did you say that you're doing this already?  
Otherwise you could end up with the controller on and sending out SOF 
packets while the root hub remains suspended indefinitely, wasting 
power.

The other issue has to do with CMD_ASE and CMD_PSE bits.  They must be
off when you enable CMD_RUN!  Otherwise the controller would try to
access the data structures for the schedules at a bad time.

Normally ehci-hcd does try to make sure the CMD_ASE and CMD_PSE are off 
when the root hub is suspended.  But some controllers (the Cell chip on 
the PS3) don't always turn these bits off when they are supposed to.  
Therefore this technique of enabling CMD_RUN during controller suspend 
should be used only when it is necessary, that is, only with the 
Synopsis-based controllers.

Also, it's not clear that all controllers will continue to work
correctly if CMD_RUN is on when they are put into low power.  That's 
another reason for doing this only when necessary.

Alan Stern

--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux