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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to