On Thu, Mar 04, 2010 at 11:49:50AM +0100, Oliver Neukum wrote:
> Am Mittwoch, 3. März 2010 11:11:30 schrieb Libin:
> > +#if 0
> > + /* Set PORT PMSC */
> > + ports = HCS_MAX_PORTS(xhci->hcs_params1);
> > + port = udev->portnum;
> > + if ((port <= 0) || (port > ports)) {
> > + xhci_warn(xhci, "Invalid port id %d\n", port);
> > + return 0;
> > + }
> > + addr = &xhci->op_regs->port_power_base + NUM_PORT_REGS * (port - 1);
> > + temp = xhci_readl(xhci, addr);
> > +
> > + switch (udev->speed) {
> > + case USB_SPEED_SUPER:
> > + /* Set U1/U2 timeout */
> > + /* FIXME: how to decide appropriate value? */
> > + temp |= PORT_U1_TIMEOUT(0x7f);
> > + temp |= PORT_U2_TIMEOUT(0xff);
> > + xhci_writel(xhci, temp, addr);
> > + xhci_dbg(xhci, "Set SS port %d U1/U2 timeout\n", port);
> > + break;
>
> It seems to me that theses values will have to be derived from the pm_qos
> framework. There's no way the kernel can come up with sensible values.
That's the first time someone has suggested the pm_qos framework for
this. I'm not familiar with it; can you tell me what you think it
should provide in this case?
I feel like the USB core should have enough information by looking at
the device descriptors in the USB tree. It has the exit latency for
U1/U2 and the hub decode latency, it knows how to follow the USB device
tree down to find the greatest exit latency, and it knows how to parse
the endpoint descriptors to find the polling intervals. All this seems
very USB-specific, so how can the pm_qos layer help?
Sarah Sharp
--
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
