On 27.09.2017 23:15, Adrian Bocaniciu wrote:
On Wed, 27 Sep 2017 11:03:41 +0300
Mathias Nyman <mathias.ny...@linux.intel.com> wrote:
Ok, please let me know which register you refer to, I'd like to get this fixed
as soon as possible.
Based on what you say I suspect that you talk about the SBRN (Serial bus
release number).
The early xhci 1.1 spec that was used to write USB3.1 SSP support stated that
SBRN contain
the serial bus specification release, (in hex) with examples of 30h for USB 3.0
and 31h for USB 3.1
Driver uses this to determine if hosts supports USB 3.0 or usb 3.1
I see that the current public xhci spec only mention 30h (USB 3.0), and in a
way that it can be
interpreted as 30 being the only option.
If this is the case then SBRN itself would be completely useless.
Why have a register with the purpose of telling which serial bus release number
the hardware
supports always forced to 30h?
Yes, the first Intel Alpine ridge based USB 3.1 SSP 10Gbps xHCI hosts had this
as 30,
Newer Intel USB 3.1 SSP capable 10Gbps xHCI hosts have it set to 31h
If vendors have interpreted it as "SBRN must equal 30h" then we need to work
around that in the driver.
We can check if the host supports USB 3.1 from the ports supported protocol
capability,
see xhci 7.2 xHCI supported protocol capability, major and minor revision
fields. These
should at least contain major=3 and minor=1 for USB 3.1 capable ports.
That at least is unambiguous in all xhci specs (early, and current public)
Yes, indeed, your guess is correct. I was writing about SBRN.
In the function "xhci_pci_setup", from the file "drivers/usb/host/xhci-pci.c", SBRN is read
and stored in "xhci->sbrn".
Then, in the function "xhci_gen_setup", from the file "drivers/usb/host/xhci.c", the value
of "xhci->sbrn" is checked. If it is 0x31, then support for 10 Gb/s is assumed.
This check was introduced in a patch from the 1st October 2015. It must have
worked once, because I have seen some Linux screen shots with the output of
lsusb showing some xHCI controller with 10 Gb/s support.
I am not aware of any USB 3.1 controllers that existed in 2015 and that could
have SBRN equal to 0x31, except for some earlier ASMedia controllers. AFAIK,
there were at least 2 versions before ASM 1142, so one or both of them must
have had SBRN equal to 0x31.
I have verified on many motherboards that both Alpine Ridge and ASM 1142 have SBRN
equal to 0x30. Moreover, the ASM 1142 datasheet says clearly that SBRN is 0x30.
Therefore, I believe that ASMedia has understood the xHCI specification exactly as
it is written, i.e. that SBRN must be 0x30, and they have reverted its value from
the earlier 0x31 to 0x30. There are at least 2 newer ASMedia USB 3.1 controllers
(2142 & 3142). I do not know what value they use for SBRN, but 0x30 is likely.
Nevertheless, even if we ignore this history of unpredictable SBRN values, it is wrong to
believe that any USB 3.1 controller supports 10 Gb/s operation. The evidence for this is
all the b*s*t advertising about "USB 3.1 Gen 1", i.e. 5 Gb/s (4 Gb/s actually)
speed.
Moreover, very soon USB 3.2 devices will appear. USB 3.2 introduces 2 more
speeds, so a USB 3.2 xHCI controller will support some or all of 4 speeds: 1 *
5 Gb/s (actually 4 Gb/s), 2 * 5 Gb/s (actually 8 Gb/s), 1 * 10 Gb/s (i.e. 10
Gb/s) and 2 * 10 Gb/s (i.e. 20 Gb/s). It is very likely that some USB 3.2 xHCI
controllers will not support all speeds, especially because the 2-lane speeds
are possible only over Type C connectors, so the same controller will support
all speeds on some motherboards but only some of them when used with Type A
connectors.
In conclusion, the supported speeds must be detected independently of the USB
release number.
The xHCI Specification describes an appropriate source for this information, at the "xHCI
Supported Protocol Capability", in the "Protocol Speed ID" Dwords.
There are chances that I might have time during this weekend to test some USB
3.1 xHCI controllers to see how this works.
If you can work on this sooner, you are welcome.
While reading the extra capability registers should be easy, what should be
thought carefully is how to change the existing structures which store
information about the xHCI controller, to accomodate the extra speeds that will
be available soon and the fact that the set of supported speeds is not
necessarily determined by the USB version number.
Like I said, while I patched my kernel and now my xHCI controllers are
recognized as supporting 10 Gb/s, the SSDs with USB-SATA bridges that I have
connected are still not recognized as also supporting 10 Gb/s. I believe that
the problem is caused by other parts of the xHCI specification that are not
implemented, but I did not have time yet to identify them.
To sum it up:
Ways to deduce host controller capable speeds:
1. From SBRN
Good: + easy, the current way
Bad: - unreliable, public spec currently forces value to be 30h (USB 3.0)
so many vendors (30h) for 3.1 SSP capable hosts
Bad: - PCI centric, SBRN is in pci config space, platform devices need their
own way to set xhci->sbrn value
Bad: - assumes host vendors only use 3.1 (30h) for 10Gbps SSP hosts.
Bad: - assumes a future spec revision always implies new mandatory
supported speeds
2. From xHCI supported protocol capability (extended capability for xHCI ports)
major and minor revision number
Good: + spec is clear on this issue, can't be interpreted in different ways.
Bad: - assumes host vendors only use 3.1 (30h) for 10Gbps SSP capable
hosts. (seems true so far for hosts)
Bad: - assumes a future spec release always implies new mandatory supported
speeds
3. From xHCI supported protocol capability (extended capability for xHCI ports)
PSI Dwords
Good: +spec is clear on this issue, can't be interpreted in different ways.
Good: +get actual real numerical value of supported speed, like 5830Mb/s
Bad: -PSI Dwords are optional, many vendors don't have them.
I already wrote xhci support for parsing PSI Dwords for xHCI and create the usb
3.1 root hub descriptor out of it.
If hosts doesnt have PSI Dwords then driver uses the default USB speed ID
mappings for root hub (xhci 7.2.2.1.)
To me it looks like first step is to use xHCI supported protocol capability
major and minor fields to
get USB release number, and also set initial supported speed.
After this we can check if we a PSI Dwords list exists, and tune the supported
speed for the host (and root hub)
Other things to consider is that we assume PSI IDs 1,2,3,4 always maps to Full,
Low, High and SuperSpeed.
I haven't seen those mapped any other way, but I think PSI Dwords don't force
this mapping.
Thanks
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
