On Thu, 2020-09-10 at 16:55 +0300, Ville Syrjälä wrote:
On Tue, Sep 08, 2020 at 02:08:17PM -0400, Lyude Paul wrote:
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
Add helpers to get the TMDS clock limits for HDMI/DVI downstream facing ports.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com
drivers/gpu/drm/drm_dp_helper.c | 116 ++++++++++++++++++++++++++++++++ include/drm/drm_dp_helper.h | 6 ++ 2 files changed, 122 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 822a30e609ef..f567428f2aef 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -643,6 +643,114 @@ int drm_dp_downstream_max_dotclock(const u8 dpcd[DP_RECEIVER_CAP_SIZE], } EXPORT_SYMBOL(drm_dp_downstream_max_dotclock);
+/**
- drm_dp_downstream_max_tmds_clock() - extract downstream facing port
max TMDS clock
- @dpcd: DisplayPort configuration data
- @port_cap: port capabilities
- @edid: EDID
- Returns HDMI/DVI downstream facing port max TMDS clock in kHz on
success,
- or 0 if max TMDS clock not defined
- */
+int drm_dp_downstream_max_tmds_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4],const struct edid *edid)+{
- if (!drm_dp_is_branch(dpcd))
return 0;- if (dpcd[DP_DPCD_REV] < 0x11) {
switch (dpcd[DP_DOWNSTREAMPORT_PRESENT] &DP_DWN_STRM_PORT_TYPE_MASK) {
case DP_DWN_STRM_PORT_TYPE_TMDS:return 165000;default:return 0;}- }
- switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
- case DP_DS_PORT_TYPE_DP_DUALMODE:
if (is_edid_digital_input_dp(edid))return 0;/** It's left up to the driver to check the* DP dual mode adapter's max TMDS clock.** Unfortunatley it looks like branch devices* may not fordward that the DP dual mode i2c* access so we just usually get i2c nak :(*/fallthrough;- case DP_DS_PORT_TYPE_HDMI:
/** We should perhaps assume 165 MHz when detailed cap* info is not available. But looks like many typical* branch devices fall into that category and so we'd* probably end up with users complaining that they can't* get high resolution modes with their favorite dongle.** So let's limit to 300 MHz instead since DPCD 1.4* HDMI 2.0 DFPs are required to have the detailed cap* info. So it's more likely we're dealing with a HDMI 1.4* compatible* device here.Forgot to mention - not directly related to this series, there's some hidden i2c bits that I think can also be probed for this sort of information on passive adapters, I know amdgpu actually supports this. I wonder how many of them also apply to older active adapters...
Something other than the normal DP dual mode stuff?
Actually that -may- have been what I was thinking of but I'm not sure, I'd probably need to look through DAL to find out