Thunderbolt 3, USB-C, and MST: Could we determine link bw more accurately?

[Lyude Paul]

Hi! So, a while ago I got myself a nice Caldigit TS3 Thunderbolt 3 dock for my
new laptop. It's awesome, and has lots of ports! But unfortunately one of the
biggest issues I've encountered with this is that the DP port is rather
unreliable when it comes to running a DP MST hub over it. To start, a diagram of
the setup I've got

Laptop's USB-C TB3 port
    |- Caldigit TS3 hub (40 GBit/s)
        |- USB-C TB3 port (5.4 GBit/s)
        |- DP++ port (2.7 GBit/s)
            |- EVGA MST hub (5.4 GBit/s)
                |- 1920x1080 display
                |- 1920x1200 display
                |- <empty>

As a note: i915 doesn't manage to train this correctly for reasons that are
understandable (this is a very, very uncommon setup with some far more uncommon
limitations that at least from all the hw I've personally seen, I haven't ever
run across before). Moving the MST hub to the USB-C TB3 port works just fine
though. I'm hoping to write some patches up for this myself already so i915 can
do link retraining with fallback link rates on both SST and MST, but that's
going to take a good bit of work to integrate cleanly with atomic.

So, onto the actual problem here: DRM has absolutely no way of knowing about the
DP++ port's capabilities. As far as I can tell there's nothing in any of the DP
specs that would be appropriate for reporting this. Sometimes the dock will
modify the DPCD from the MST hub so that it reads 2.7 GBit/s instead of 5.4, but
the hub does not do this consistently and I haven't yet figured out why.

While link fallback is always an option we should be supporting, it seems like a
rather hacky method of something that seems like should be much easier to do.
Additionally, the amount of time we already spend with trial and error modesets
with MST hubs, specifically problematic ones (which is a LOT of them), is not
great. On this EVGA hub, it messes up some of the DP AUX responses at times
causing it to report devices that aren't actually there, which makes i915 have
to redo the whole modesetting process from the start. It works, but it's a lot
slower then it needs to be.

This has been making me ponder the question: is there any possible way, through
USB-C and/or Thunderbolt 3 protocols, that we could actually teach DRM to query
the capabilities of the DP++ port so it knows ahead of time to limit the link
rate it tries to train with regardless of what the MST hub says? This would
speed up the whole process a heck of a lot, and seems like it shouldn't be super
difficult to implement. I've been looking through all of the docs I can get my
hands on to try to figure something out. I've gone through the USB 3.2 docs and
the UCSI specification from intel. The only lead I've managed to find thus far
for determining the link bandwidth is the GET_CABLE_PROPERTY UCSI command which
seems to have a bitfield indicating the maximum link rate supported. That being
said, I'm assuming "cable" is just referring to the cable connecting us to the
hub and not the individual downstream ports, so I'm not sure if we could
actually derive any details about the DP++ port from there.

So, I figured I've been talking about this enough on IRC that it's about time I
poke the whole mailing list to see if anyone knows anything more about this that
I don't yet. I'm completely open to other ideas on solving this issue as well,
so don't be shy!
-- 
Lyude Paul <lyude at redhat.com>
Red Hat