On Wed, 2010-03-03 at 11:18 -0800, Sarah Sharp wrote:
> All hosts and devices must support U1/U2 to pass USB-IF certification.
> If you have a specific host that doesn't support it (even if it's a
> prototype), then skip setting the U1/U2 timeout based on that host's PCI
> vendor and product ID. But let products that have passed certification
> get better power management under Linux by setting the U1/U2 timeout.
Thanks for the suggestion.
> > +
> > + switch (udev->speed) {
> > + case USB_SPEED_SUPER:
> > + /* Set U1/U2 timeout */
> > + /* FIXME: how to decide appropriate value? */
>
> Yes, that is the issue. You need to do more gathering of information,
> which is why this should be in the USB core, not the xHCI driver. khubd
> in the USB core should set the policy for U1 and U2 timeouts for all the
> hubs, including the root hub.
>
> You need to look at several factors when setting the U1/U2 timeout for a
> device. Each device under a hub has a max exit latency for coming out
> of U1 and U2. You don't want the hub to come out of U2 (to U0) and then
> try to go back into U1 when the devices below it are still exiting U2.
> So you have to propagate the highest exit latency up the device tree and
> set the hub's timeouts based on that. Each hub also has a Hub Header
> Decode Latency that you have to take into account.
>
> You also need to take into account the periodic endpoints on all the
> devices below the hub. If you're polling an endpoint at 1ms, but the
> maximum exit latency for that path to the device is high (close to 1ms),
> it may not save any power to ping-pong the link between U0 and U2.
>
> All this makes it complicated enough to push into khubd. I have to NAK
> this patch for now until there's a better solution. It's a moot point,
> since the patch doesn't do anything.
Really thanks for the comment. I'll investigate the implementation
again. Seems you are right, the value cannot be decided by xHCI. I'll
withdraw this patch until I have a better solution.
> Did you mean to say HS port here? This will fall through for FS and LS
> ports too. Also, shouldn't enabling remote wakeup go into the port
> remote wakeup patch (patch 2)? I don't understand what remote wakeup
> has to do with link power management.
What I really mean is USB2 protocol port here. And the remote wakeup
should be removed.
--
Thanks,
Andiry
--
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
