Re: [RFC 3/4] usb: Send Set SEL before enabling parent U1/U2 timeout.

Re: [RFC 3/4] usb: Send Set SEL before enabling parent U1/U2 timeout.

[Sarah Sharp]

On Fri, Oct 19, 2012 at 07:18:00PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Oct 08, 2012 at 03:47:35PM -0700, Sarah Sharp wrote:
> > On Mon, Oct 08, 2012 at 04:05:00PM -0400, Alan Stern wrote:
> > > On Mon, 8 Oct 2012, Sarah Sharp wrote:
> > > 
> > > > The Set SEL control transfer tells a device the exit latencies
> > > > associated with a device-initated U1 or U2 exit.  Since a parent hub may
> > > > initiate a transition to U1 soon after a downstream port's U1 timeout is
> > > > set, we need to make sure the device receives the Set SEL transfer
> > > > before the parent hub timeout is set.
> > > 
> > > Just a question, not a comment on the patch.  Why is "Set SEL" needed?  
> > > Doesn't the device already know its own exit latencies?  After all, the 
> > > values come from descriptors that were originally provided by the 
> > > device.
> > 
> > The device knows its own exit latency, but it doesn't know the exit
> > latencies for the path above it.  It could be directly attached to the
> > roothub (which may have a bigger exit latency than the device) or a
> > couple tiers deep in the tree.  If the device wants to be smart about
> > when it requests to come out of U1 or U2, then it needs to know the
> > whole path exit latency.
> > 
> > For example, maybe there's an interrupt endpoint on a self-powered radio
> > device.  As soon as the device doesn't have any data to send, it
> > transmits an NRDY (Not Ready) response to the request for data.  Then it
> > puts its link into U1 or U2 (or maybe the host controller does this when
> > the U1/U2 timeouts expire).
> > 
> > Later, the device starts receiving a packet.  Let's assume it takes some
> > time to process that packet.  If the device knows how long it takes to
> > wake up the link and send an ERDY to the host, it can parallelize the
> > link wakeup and the packet processing.  It doesn't want to send an ERDY
> > too soon, because the host could ask for the data before it's ready.  So
> > the device needs to know the time it takes for the link to come out of
> > U1 or U2, the time it takes for the host to process the ERDY, and the
> > time it takes for the request for data to reach the device.  That's what
> > the Set SEL request does.
> > 
> > Of course, I'm not a USB device designer, so I don't know how the Set
> > SEL command is really used.  Felipe, do we use it at all in any of the
> > Linux USB 3.0 gadget drivers?
> 
> sorry for the delay. Currently we're not using Set SEL at all, but we
> could use, eventually, to pass it to pm_qos ?!? Just a thought.

Yes, I think it could be useful to pass that information on to pm_qos.
I don't think the subsystem currently supports multiple power states
though, but Rafael would know.  On the host side, it's all custom code
to deal with the USB device U1/U2 low power states.  Only the U3 (device
suspend) is handled by the runtime PM subsystem.

Rafael is adding support for a power-off pm_qos flag, and I'm not sure
if it makes sense to add support for multiple power state flags as well.
Probably we should see how the new pm_qos flag architecture shakes out,
and then decide whether we should tackle that.

Sarah Sharp