On Tue, Jun 26, 2012 at 11:05:34AM +0800, Andiry Xu wrote:
> On 06/26/2012 06:39 AM, Sarah Sharp wrote:
> >Some xHCI host controllers may have optional support for Latency
> >Tolerance Messaging (LTM). This allows USB 3.0 devices that support LTM
> >to pass information about how much latency they can tolerate to the xHC.
> >A PCI xHCI host will use this information to update the PCI Latency
> >Tolerance Request (LTR) info. The goal of this is to gather latency
> >information for the system, to enable hardware-driven C states, and the
> >shutting down of PLLs.
> >
> >Signed-off-by: Sarah Sharp<sarah.a.sharp@xxxxxxxxxxxxxxx>
> >---
> > drivers/usb/host/xhci-hub.c | 5 +++++
> > drivers/usb/host/xhci.h | 2 +-
> > 2 files changed, 6 insertions(+), 1 deletions(-)
> >
> >diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> >index 2732ef6..2976b66 100644
> >--- a/drivers/usb/host/xhci-hub.c
> >+++ b/drivers/usb/host/xhci-hub.c
> >@@ -508,12 +508,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
> > if (hcd->speed != HCD_USB3)
> > goto error;
> >
> >+ /* Set the U1 and U2 exit latencies. */
> > memcpy(buf,&usb_bos_descriptor,
> > USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE);
> > temp = xhci_readl(xhci,&xhci->cap_regs->hcs_params3);
> > buf[12] = HCS_U1_LATENCY(temp);
> > put_unaligned_le16(HCS_U2_LATENCY(temp),&buf[13]);
> >
> >+ /* Indicate whether the host has LTM support. */
> >+ temp = xhci_readl(xhci,&xhci->cap_regs->hcc_params);
> >+ buf[8] = HCC_LTM(temp);
>
> So buf[8] would be (1 << 6) if it supports LTM, right?
>
> However, in ss_cap descriptor, USB_LTM_SUPPORT is defined as (1 <<
> 1). So the check in patch2 will never be true.
D'oh! Good catch, I'll fix that.
> >+
> > spin_unlock_irqrestore(&xhci->lock, flags);
> > return USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE;
> > case GetPortStatus:
> >diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> >index de3d6e3..6426185 100644
> >--- a/drivers/usb/host/xhci.h
> >+++ b/drivers/usb/host/xhci.h
> >@@ -114,7 +114,7 @@ struct xhci_cap_regs {
> > /* true: HC has Light HC Reset Capability */
> > #define HCC_LIGHT_RESET(p) ((p)& (1<< 5))
> > /* true: HC supports latency tolerance messaging */
> >-#define HCC_LTC(p) ((p)& (1<< 6))
> >+#define HCC_LTM(p) ((p)& (1<< 6))
>
> I don't see the reason to change the name here. xHCI spec defines
> the bit as LTC, and the meaning is pretty clear. However, this is up
> to you.
It was just confusing to have multiple acronyms for the same thing. But
you're right that it's defined as LTC in the xHCI spec, so I guess I'll
just leave it as LTC.
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
