Device Qualifier Descriptor

[nvd]

Hi All,
 I am confused about How the host tells the device to switch the current speed?

 I have a device which can operate at both HS as well as FS. User can select the speed of operation using an API for this driver.
 Now, if HS is selected, what should be my response to Device Qualifier Descriptor request?
 Can I stall it?
 As a HS device i guess Compliance tests need to be run at both HS and FS.
 Meaning, HS device must be able to work at FS if connected through 1.x hub or to 1.x host.
 
 If user selected FS as default speed, this device will not respond at high speed during USB reset process.
 
 This is more important for Compliance test. I would like to know, how to go about compliance test with this user configuration?
 Moreover, do we need to get compliance test done with every revision of the software driver? this seems impossible though

 One more question is, With Same Vid, Pid, etc, will windows remember the Speed of the device?
 If i connect the device with HS first. then change the configuration to FS, will Windows treat it as new device or same HS device and declare that it is not working properly since it is not responding at HS?

Regards,
Nitin
 

[Jan Axelson]

On device attachment, the host attempts high-speed signaling. If the device responds, the host communicates at high speed. Otherwise, the host uses full speed. This occurs before the host knows anything about the device.

A driver that allows user selection of device speed would need to have the ability to send a request to cause the device to simulate device detach, then reattach at the selected speed.

[nvd]

Thanks Jan,
I am providing the user selection for speed at initialization time only.

If user selects HS, the driver would work at HS if connected to 2.0 host.
If connected to 1.x host (or through 1.x hub) driver will run at FS (automatically)

If user selects FS, driver will not respond to HS negotiation from host.


With this I am thinking of going for compliance test with HS option selected.

Does this arrangment sound OK?

regards,
Nitin

[Jan Axelson]

That could work if the user selects the speed on the device, not the host.

The HS option is the normal way devices operate and thus shouldn't be a problem with compliance testing. I don't know if having a "FS" option would cause a problem, but since compliance tests don't look for anything like that, I don't know why it would be a problem.

[Barry Twycross]

I'd have the device at HS respond correctly as a high speed device. (Ie return the qualifier descriptors.) After all its a high speed device.

At FS I'd have it behave as a FS device, the host shouldn't even ask for the qualifier, if it is asked, I'd STALL it. That is what the spec actually says "If a full-speed only device (with a device descriptor version number equal to 0200H) receives a GetDescriptor() request for a device_qualifier, it must respond with a request error."

[nvd]

Thanks Jan, Barry
 It confirms that the driver arrangement is OK. Actually I personally do not want to give the FS only user selection option, but I am asked to do so

 So, only doubt for me is:
 When a HS device (capable of FS) is connected, it must respond with valid Dev_Qualifier Descriptor when asked for.
 Now Host knows that the device can also operate at FS.
 In Which condition will host ask Device to work at FS? (off course this will involve a USB reset)
 Or it is only for the conditions where HS device is connected to 1.x host or through 1.x hub?

Regards,
Nvd

[Jan Axelson]

A host can do whatever it wants, but normally, yes, it would use high speed unless it's a 1.x host or the device has an upstream 1.x hub.

What is the reason for having speed selection on the device?

[nvd]

Its just that the Core we have is capable of working in FS or HS, and we feel that customer may ask for such speed selection....may be he wants to make a FS only product. So the driver needs to handle it.
Does it look like an overhead?

[Bret]

The way the USB architecture is designed, the upstream hardware (hosts and hubs) will automatically try to connect at the highest speed possible.  There are some exceptions to this rule, but it absolutely is not universal.  If you want to guarantee a device will attach at FS, you must do it from the downstream side (the device itself), not the upstream side (the host or hub or software).  And, once a device has been configured, you can't change the speed without disconnecting.

You will need to signal your device somehow (a physical switch on the device that the user can toggle, or a custom software control request), which will cause the device to disconnect and then reconnect and ignore the high-speed hardware signalling.  If you are using any default drivers, you may also need to come up at FS with a different device id or version number or something to differentiate things, or the default drivers may get confused.  If you're writing a custom driver, that may not be an issue.

[Barry Twycross]

We do our best to make sure the device is connected at the highest possible speed. We'd get a bug if we managed to enumerate a high speed capable device as full speed on a high speed capable port. The only time a high speed capable device doesn't get enumerated as high speed is if its attached to a full speed only port. That basically means there's a full speed hub in the way.

We couldn't actually deliberately enumerate a high speed device as full speed (on a high speed port) if we wanted to. I think we were asked to do that once, and couldn't.

The other possible way it might happen is if there is no EHCI driver (assuming an EHCI controller). EHCI was architected so that the companion controller would run the port in the absence of an EHCI driver. The port defaults to the companion controller, and the first thing the EHCI driver does is to switch it all to the EHCI controller.

[nvd]

Thanks for the detailed reply, Bret and Barry.
 
 With the speed selection option that I mentioned, I tested my driver for both speeds with Windows7-32bit host (EHCI controller).
 With the same VID,PID info, device gets enumerated at FS as well as HS. This seems to work without detaching the device or uninstalling drivers on windows.
 May be I should confirm with previous versions of windows.
 
 Can you please suggest where I can look for on PC, what Windows is actually doing with the device? (any log messages or such information on windows??)
 
 The thing I haven't yet actually tested is connecting to host through 1.1 hub. (can't find a 1.1Hub easily).

nvd

[nvd]

Just found Jan Reply in other thread indicating to look at http://sourcedaddy.com/windows-7/using-setupapi-log-file.html
Will verify and post the observations.

[Bret]

We couldn't actually deliberately enumerate a high speed device as full speed (on a high speed port) if we wanted to. I think we were asked to do that once, and couldn't.

That would be a limitation of your device hardware/firmware.  Basically, it won't allow the high-speed detection signalling to be ignored like a full-speed-only device does.  I would imagine very few, if any, HS capable devices even have the ability to ignore the HS detection signalling.  Speed is king these days, not control.

The other possible way it might happen is if there is no EHCI driver (assuming an EHCI controller). EHCI was architected so that the companion controller would run the port in the absence of an EHCI driver. The port defaults to the companion controller, and the first thing the EHCI driver does is to switch it all to the EHCI controller.

That's the exception I was talking about -- and the only one I know of.  If there are FS/LS companion controllers (UHCI or OHCI) alongside the HS (EHCI) controllers, you can (with software) force individual ports to the FS controller.  I don't think Windows actually lets you control individual ports like this, but the EHCI hardware supports it (I do it on a regular basis).  You can also disable the entire Windows EHCI driver, which will force all ports to the companion controller(s).

The problem is, modern hardware (made over the last few years) doesn't always have companion controllers.  There is only an EHCI controller (no UHCI or OHCI), and an integrated hub.  The hub handles all of the speed connection details instead of the host.  Hubs do not allow control of individual port speeds the way EHCI (when configured with FS companion controllers) does.

[Barry Twycross]

We couldn't actually deliberately enumerate a high speed device as full speed (on a high speed port) if we wanted to. I think we were asked to do that once, and couldn't.

That would be a limitation of your device hardware/firmware.  Basically, it won't allow the high-speed detection signalling to be ignored like a full-speed-only device does.  I would imagine very few, if any, HS capable devices even have the ability to ignore the HS detection signalling.  Speed is king these days, not control.

We were on the host side of that. We couldn't think of a way to enumerated a specific device as full speed, but enumerate every other device properly.

From the device side, its entirely in the device's control whether it starts the high speed detection or not. It starts with the device sending the chirp K. Device cores I've worked with have had a bit to disable the chirp K. We've even managed to have full speed devices enumerate at high speed when they decided to issue a remote wakeup during reset. (No good comes of this.)