On Tue, Mar 08, 2011 at 02:35:51PM -0500, Alan Stern wrote:
> On Mon, 7 Mar 2011, Sarah Sharp wrote:
>
> > This patch changes the xHCI driver to allocate two roothubs. This touches
> > the driver initialization and shutdown paths, roothub emulation code, and
> > port status change event handlers. This is a rather large patch, but it
> > can't be broken up, or it would break git-bisect.
> >
> > Make the xHCI driver register its own PCI probe function. This will call
> > the USB core to create the USB 2.0 roothub, and then create the USB 3.0
> > roothub. This gets the code for registering a shared roothub out of the
> > USB core, and allows other HCDs later to decide if and how many shared
> > roothubs they want to allocate.
> >
> > Make sure the USB core marks the xHCI host controller's primary roothub as
> > the USB 2.0 roothub. This ensures that the high speed bus will be
> > processed first when the PCI device is resumed, and any USB 3.0 devices
> > that have migrated over to high speed will migrate back after being reset.
> > This ensures that USB persist works with these odd devices.
> >
> > Mark the xHCI USB2 roothub as having an integrated TT. Like EHCI host
> > controllers with a "rate matching hub" the xHCI USB 2.0 roothub doesn't
> > have an OHCI or UHCI companion controller. It doesn't really have a TT,
> > but we'll lie and say it has an integrated TT. We need to do this
> > because the USB core will reject LS/FS devices under a HS hub without a
> > TT.
>
> We probably should rename the variable from has_tt to something like
> handles_fs_ls, since the concept it describes is more general than
> having an integrated TT.
Sure. Maybe as a separate patch.
> ...
>
> > diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
> > index 2707971..20612ca 100644
> > --- a/drivers/usb/core/hcd-pci.c
> > +++ b/drivers/usb/core/hcd-pci.c
> > @@ -200,6 +200,18 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
> > retval = -ENOMEM;
> > goto disable_pci;
> > }
> > + if ((driver->flags & HCD_MASK) == HCD_USB3) {
> > + /* Mark the first roothub as being USB 2.0.
> > + * The xHCI driver will register the USB 3.0 roothub.
> > + */
> > + hcd->speed = HCD_USB2;
> > + /*
> > + * USB 2.0 roothub under xHCI has an integrated TT,
> > + * (rate matching hub) as opposed to having an OHCI/UHCI
> > + * companion controller.
> > + */
> > + hcd->has_tt = 1;
> > + }
>
> The hcd->has_tt part can be moved into xhci-hcd.
Ok, so I can safely set the has_tt flag after the roothub has been
allocated with a call to usb_add_hcd()? There's nothing in the roothub
allocation that relies on it?
> It would be nice to move the hcd->speed part as well (this strong
> coupling between hcd-pci and xhci-hcd is undesirable), but that would
> cause the root hub to be registered while it is still marked with the
> wrong speed.
Yes, I wish I could move the hcd->speed into the xHCI driver. I had
thought about lying and setting the xHCI driver speed flags to HCD_USB2.
Then xhci-pci.c could set the hcd->speed for the USB3 roothub after
usb_create_shared_hcd() is called. However, I need to evaluate the
other side effects of setting the xHCI driver HCD_MASK bits to HCD_USB2.
> > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > index 3ec5ae2..32afad5 100644
> > --- a/drivers/usb/host/xhci-hub.c
> > +++ b/drivers/usb/host/xhci-hub.c
> > @@ -28,13 +28,20 @@
> > #define PORT_RWC_BITS (PORT_CSC | PORT_PEC | PORT_WRC | PORT_OCC | \
> > PORT_RC | PORT_PLC | PORT_PE)
> >
> > -static void xhci_hub_descriptor(struct xhci_hcd *xhci,
> > +static void xhci_hub_descriptor(struct usb_hcd *hcd, struct xhci_hcd *xhci,
> > struct usb_hub_descriptor *desc)
> > {
> > int ports;
> > u16 temp;
> >
> > - ports = HCS_MAX_PORTS(xhci->hcs_params1);
> > + if (hcd->bcdUSB == HCD_USB3)
>
> Isn't this supposed to be hcd->speed now?
Yes, that line probably got replaced later in the patchset. I'll
eliminate it here.
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
