From: Nathan Schulte <nmschulte@gmail.com>
To: intel-gfx@lists.freedesktop.org
Subject: i915: allow forcing SST on DisplayPort connectors
Date: Thu, 10 Mar 2016 17:43:22 -0600 [thread overview]
Message-ID: <1457653404-19950-1-git-send-email-nmschulte@gmail.com> (raw)
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
next reply other threads:[~2016-03-10 23:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 23:43 Nathan Schulte [this message]
2016-03-10 23:43 ` [PATCH 1/2] [i915] add module param "force_dp_sst" Nathan Schulte
2016-03-11 13:45 ` Jani Nikula
2016-03-10 23:43 ` [PATCH 2/2] [i915] move bools to end of i915_params struct Nathan Schulte
2016-03-11 7:40 ` ✗ Fi.CI.BAT: failure for series starting with [1/2,i915] add module param "force_dp_sst" Patchwork
2016-03-11 8:47 ` Joonas Lahtinen
2016-03-14 16:36 ` [PATCH v2] i915: module param to disable DisplayPort MST Nathan Schulte
2016-03-14 16:36 ` [PATCH] [i915] add module param "enable_dp_mst" Nathan Schulte
2016-03-15 8:43 ` Daniel Vetter
2016-03-15 15:14 ` [PATCH v3] drm/i915: " Nathan Schulte
2016-03-16 15:40 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1457653404-19950-1-git-send-email-nmschulte@gmail.com \
--to=nmschulte@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox