Hi,
Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> writes:
[snip]
>> 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.
Indeed, they are optional. However if PSIC is 0, then the default
mapping *must* be assumed. Default mapping, on public spec, only species
up to 5Gbps. So this means that SSP hosts *must* have PSIC > 0.
> 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.)
which only define speeds up to 5Gbps
> 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)
Actually, I think we should go the other way around:
psic = read_psic_from_register();
if (psic)
setup_supported_speeds_based_on_psic(xhci, psic);
else
setup_supported_speeds_using_default_mappings(xhci);
This should be enough to sort everything out (assuming no-quirky HW, of
course). Even if a new spec is released defining a new default mapping
for 10Gbps and/or adding 0x31 to SBRN, we really don't need to rely on
that.
Well, maybe we can rely on SBRN to append a new default
mapping. Something like (also considering possible quirky hosts):
static bool xhci_30_supports_ssp(struct xhci_hcd *xhci)
{
sbrn = read_sbrn_maybe(xhci);
if (!sbrn)
return false;
if (sbrn == 0x30 && xhci->quirks & XHCI_SBRN30_SUPPORTS_SSP)
return true;
return false;
}
static void setup_supported_speeds_using_default_mappings(struct xhci_hcd *xhci)
{
[...]
sbrn = read_sbrn_maybe(xhci);
if (!sbrn)
return;
/*
* xhci revision foo.bar defines a new SBRN of 0x31 for USB3.1
* hosts.
*
* That same spec revision, also defines a new default mapping
* for 10Gbps. Let's append it.
*
* Note that there are known quirky hosts which have SBRN equals
* to 0x30, but are, indeed, 10Gbps-capable hosts which PSIC
* equal to 0. Also handle these cases.
*/
if (sbrn == 0x31 || xhci_30_supports_ssp(xhci))
append_10gbps_default_mapping(xhci);
[...]
}
> Other things to consider is that we assume PSI IDs 1,2,3,4 always maps
> to Full, Low, High and SuperSpeed.
That's the default mapping. If PSIC > 0 you don't need default
mapping. Or rather, shouldn't need. Imagine the following situation:
Currently xhci always adds default mapping. Now say PSIC is > 0 and ID 3
is, according to PSI Dwords, used for 10Gbps. Now you're gonna have ID 3
being used for 10Gbps and 480Mbps.
IMHO, the first step should be extracting all the current magic (without
changing it in any way) to a separate function. Then you can start
reasoning about how to best parse/decode it.
> I haven't seen those mapped any other way, but I think PSI Dwords
> don't force this mapping.
they don't appear to, no. Only default mapping forces that.
--
balbi
Attachment:
signature.asc
Description: PGP signature
