On Thu, 18 Nov 2010, Sarah Sharp wrote: > > So we definitely need to handle the LS/FS/HS root-hub ports before > > resuming the SS ports. You might be able to make that work by > > numbering the ports properly (put all the SS ports at the end). This > > may fix part of Don's problem without the full-blown root-hub split. > > Hmm, ok, I'll look into that after Don tests the first patchset. All > the xHCI host controllers I've seen advertise the SS ports first. IIRC, Don's previous log showed that the SS ports were 0 and 2, and the corresponding LS/FS/HS ports were 1 and 3. Or something like that -- interleaved rather than sequential. > > Do you have any idea why the device switched over to high speed in the > > first place? > > I'd have to watch with a USB 3.0 bus analyzer to see what's really going > on. And I'd have to read carefully through the parts of the USB-3.0 spec that define the electrical signalling used during suspend and resume. Something I have carefully avoided for quite some time now... > > Well, "disappears" is too strong a word. The device may well still be > > there and still be active -- it's just that for whatever reason, the > > kernel thinks something bad has happened to it. If we were to assign > > the same address to a different device without disabling the port, we > > could end up in a situation where two active devices are using the same > > address. Not good. > > Oh, I see. That shouldn't be an issue with USB 3.0 devices, since > packets are routed, not broadcast, on the USB 3.0 wires. But that's > definitely an argument for allowing the USB core to disable USB 2.0 > ports under an xHCI host. Indeed. Which leads me to wonder why devices on a USB-3 bus need to have addresses at all. > > Why on earth didn't the designers just specify that ports 1 - N would > > always be SuperSpeed and ports (N+1) - 2N would always be the > > corresponding LS/FS/HS connections? > > Because they wanted to allow designers to put more of one type of > connector than the other on the box. For example, you could expose only > two SuperSpeed ports and six LS/FS/HS ports. Then the xHCI host > controller would have 2 PORTSC registers with SuperSpeed capabilities, > and eight LS/FS/HS PORTSC registers (two of which correspond to the SS > ports, but you wouldn't be able to tell which ones). Okay, I guess that makes sense. They still could have defined things in a way that was more strict and easier for people to use. > > That's right. There's special code in core/hcd-pci.c to handle this, > > both matching up controllers with their companions and waiting during > > resume. (The implication, by the way, is that when you register your > > two usb_hcd structures, the USB-2 structure must be registered before > > the USB-3 structure so that it will be resumed first.) > > Ok, I'll have to look into that. The code originally registered the USB > 3.0 roothub first, to ensure all resources got allocated to it, and the > PCI device stored that usb_hcd in its private pointer. But I hadn't > gotten to the PCI suspend/resume yet, and I guess that will have to > change. It shouldn't be a big deal. You can store whichever you like in the PCI device's private pointer, regardless of registration order. > > There's also special code in core/driver.c:usb_resume_device(); > > non-root devices on a LS/FS bus must not be resumed until after the > > root hub on the companion HS bus. I don't know if you will need > > anything comparable. > > I'm not sure yet. I haven't tried testing suspend with a USB 3.0 hub > yet. But I suspect if the USB 3.0 portion of the hub isn't resumed > before the USB 2.0 portion, then the USB 3.0 devices under it will show > up as High Speed devices. They'll come back from suspend, Why will they come back from suspend? (See, this is where I need to understand the spec...) > not find the > SuperSpeed terminations, and then switch over to HS. But if the USB 3.0 > hub is resumed first, it will turn on terminations to all downstream > ports and the devices will connect at SS. I'm going to ask the hub guy > at Intel about it. Good idea. Keep in mind that the controller is treated as a single device (i.e., the resume code in hcd-pci.c will call the pci_resume method only for the hcd stored in the private pointer, not for the other one) whereas the root hubs will be treated as two devices (i.e., calls will be made to the bus_resume methods in both hcds). Alan Stern -- 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
