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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
