Hi all,
how do I distinguish wether my usb 2.0 high speed device is connected to
XHCI or EHCI host?
thanks,
/Uwe
uwekirst wrote:
how do I distinguish wether my usb 2.0 high speed device is connected to
XHCI or EHCI host?
Why does it matter?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Am 12.09.2012 18:44, schrieb Tim Roberts:
uwekirst wrote:
> how do I distinguish wether my usb 2.0 high speed device is connected to
> XHCI or EHCI host?
Why does it matter?
I think I found a compatibility issue and need to write some special
code for XHCI.
/Uwe
uwekirst wrote:
Am 12.09.2012 18:44, schrieb Tim Roberts:
> uwekirst wrote:
>> how do I distinguish wether my usb 2.0 high speed device is connected to
>> XHCI or EHCI host?
> Why does it matter?
I think I found a compatibility issue and need to write some special
code for XHCI.
Interesting. You shouldn’t be able to tell the difference.
Remember that XHCI on Windows 7 is an entirely different world from XHCI
on Windows 8+. In Windows 7, you’re using a driver stack from the host
controller manufacturer, and no one knows what rules they followed.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Am 12.09.2012 19:02, schrieb Tim Roberts:
Interesting. You shouldn’t be able to tell the difference.
Remember that XHCI on Windows 7 is an entirely different world from XHCI
on Windows 8+. In Windows 7, you’re using a driver stack from the host
controller manufacturer, and no one knows what rules they followed.
It seems to me that the frame numbering procedure differs by one frame.
/Uwe
uwekirst wrote:
Am 12.09.2012 19:02, schrieb Tim Roberts:
> Interesting. You shouldn’t be able to tell the difference.
>
> Remember that XHCI on Windows 7 is an entirely different world from XHCI
> on Windows 8+. In Windows 7, you’re using a driver stack from the host
> controller manufacturer, and no one knows what rules they followed.
>
It seems to me that the frame numbering procedure differs by one frame.
In what way? Do you mean that fetching the current frame number gets
you the number of the NEXT frame, or something like that? How are you
using the frame number?
We had a discussion about the frame number handling in 2005 that
referred to the EHCI spec:
http://www.osronline.com/showThread.cfm?link=74871
Do you actually know that the XHCI spec handles this differently? I’d
be shocked by that, because an XHCI controller is supposed to expose a
completely EHCI-compatible host controller when it finds a USB 2
device. If there really is a behavioral difference, I’m guessing it’s a
bug in your host controller’s driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Am 12.09.2012 19:44, schrieb Tim Roberts:
uwekirst wrote:
> Am 12.09.2012 19:02, schrieb Tim Roberts:
>> Interesting. You shouldn’t be able to tell the difference.
>>
>> Remember that XHCI on Windows 7 is an entirely different world from XHCI
>> on Windows 8+. In Windows 7, you’re using a driver stack from the host
>> controller manufacturer, and no one knows what rules they followed.
>>
> It seems to me that the frame numbering procedure differs by one frame.
In what way? Do you mean that fetching the current frame number gets
you the number of the NEXT frame, or something like that? How are you
using the frame number?We had a discussion about the frame number handling in 2005 that
referred to the EHCI spec:
http://www.osronline.com/showThread.cfm?link=74871Do you actually know that the XHCI spec handles this differently? I’d
be shocked by that, because an XHCI controller is supposed to expose a
completely EHCI-compatible host controller when it finds a USB 2
device. If there really is a behavioral difference, I’m guessing it’s a
bug in your host controller’s driver.
Ok, I narrowed it down.
A vendor supplied XHCI driver under windows 7 behaves different to the
Microsoft XHCI driver under windows 8 (in high speed mode)
Let’s say you want to start isoch streaming at frame number x.
In my driver I read the current frame number and add an offset and use
the result as startframe for the isoch transfer.
Now calculate y = x mod 8 to get the microframe number within 1 ms. The
microsoft driver starts streaming at microframe y = 7, the vendor
supplied driver starts streaming at microframe y = 0.
/Uwe
uwekirst wrote:
Ok, I narrowed it down.
A vendor supplied XHCI driver under windows 7 behaves different to the
Microsoft XHCI driver under windows 8 (in high speed mode)
Let’s say you want to start isoch streaming at frame number x.
In my driver I read the current frame number and add an offset and use
the result as startframe for the isoch transfer.
Now calculate y = x mod 8 to get the microframe number within 1 ms.
No, it doesn’t. You can’t get the current microframe number – only the
frame number. And in an isochronous request, you are requesting a frame
number, not a microframe number.
The microsoft driver starts streaming at microframe y = 7, the vendor
supplied driver starts streaming at microframe y = 0.
What is your isochronous interval? If the interval is 1, then you
should see a request in every microframe. If the interval is 3 (meaning
8 microframes, or one frame), then there is no promise in any document
that says where in the microframe your request will be sent. Indeed,
the controller is not even obligated to send your request in the same
microframe in every frame (although it usually will).
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Am 13.09.2012 18:45, schrieb Tim Roberts:
No, it doesn’t. You can’t get the current microframe number – only
the frame number. And in an isochronous request, you are requesting a
frame number, not a microframe number.
Yes, I know. I was talking about the microframe numers that I have
measured with a bus analyser.
I set the interval to 1 (every frame).
I seems that controllers from different vendors behave differnt. I
expected that the streaming starts allways at a 1ms boundary, but I
found that one host controller starts a microframe 7 (at the end of a
frame) and another starts at microframe 0 (at the beginning of a frame).
My last theory was that it seem to depend on the hardware implemenation
of the host controller chip and is not under control of the driver.
thanks,
/Uwe
uwekirst wrote:
Am 13.09.2012 18:45, schrieb Tim Roberts:
> No, it doesn’t. You can’t get the current microframe number – only
> the frame number. And in an isochronous request, you are requesting a
> frame number, not a microframe number.
Yes, I know. I was talking about the microframe numers that I have
measured with a bus analyser.
I set the interval to 1 (every frame).
High-speed or full-speed? An interval of 1 in high-speed is every
microframe.
I seems that controllers from different vendors behave differnt. I
expected that the streaming starts allways at a 1ms boundary, but I
found that one host controller starts a microframe 7 (at the end of a
frame) and another starts at microframe 0 (at the beginning of a frame).
Quite likely. How could this possibly matter? The only guarantee is
“once per frame”. There’s nothing more precise than that. It would be
perfectly valid for a host controller to put you in microframe 6 in
frame N, and microframe 2 in frame N+1. Most don’t, but it’s not
prohibited.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.