This adds a module parameter to the i915 DRM driver: force_dp_sst. This parameter allows forcing the use of single-stream transport (SST) for DisplayPort connections (thus effectively disabling multi-stream transport, MST). This is immediately useful as a debugging feature, but is also useful in real-world cases.
In my case, I'm simply looking to free up a CRTC when I use an MST-capable DisplayPort splitter (which doesn't allow the user a choice of SST or MST mode, defaulting to MST ("passive") splitting on MST capable hardware). This allows, in my case with Intel Haswell graphics chipset, the ability to drive up to six individual monitors. Of course the only bounds here are the bandwidth and protocol limitations of DP and the limits of the specific splitting hardware in use, so real-world use-cases are abound.
Ultimately, I was hoping to add support for configuring this (forcing SST/disabling MST) on a per-connector basis via e.g. sysfs. I'm told I'm the only user that's asking for user-space control of the DisplayPort topology, but I feel that this request is only going to become more popular as users become more aware of the power that DisplayPort provides via protocol (MST). At this point, the maintenance costs are probably not worth the trouble, which is understandable.
That said, I'm hopeful these changes will allow emulating such a feature: by changing the module-wide preference prior to establishing a connection on a connector. It's possible this won't play out in practice, due to my unfamiliarity with the code stack/arch. (state), but also due to error handling/recovery logic which I haven't accounted for. That is, the check in intel_dp_probe_mst might be too late, or need sibling logic elsewhere, or extra state tracking, to properly handle recovery on a per-connector/connection basis.
It's possible that I've even missed some error handling/recovery logic/assumption that makes this unstable for even module-wide support. As such, this parameter is marked unsafe (auto-tainting).
--
Nathan Schulte
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
