890GX/HD4290 dual display question

[nanonyme]

Or maybe 'D'? I'd at least think DisplayPort was a digital output.

[agd5f]

I feel special


That would be the goodness
You think that the "e" option (output forced to ON) would take care of the "connected" state?

If it would, could be fixed to, or an additional option added to, then that, along with setting a sensible default sink_type would bring this broken board into a manual-but-usable state... i.e.
video=DisplayPort-0:1920x1200@60e

Yeah, I think that should do it.

Is it *possible* that DP does NOT require the AUX channel to operate? One line in the 780 document you linked to somewhat implies that it may not be required... in section 1.2.12 on page 1-8, it says "Supports the Auxilary Channel (AUX CH)", which is presented as a FEATURE. If it was a hard requirement, why would it be presented as a feature?

AUX is required for DP since you need AUX to communicate with the monitor (get the EDID, DPCD, train the link, etc.).

[droidhacker]

Yeah, I think that should do it.

About this patch:
http://lists.freedesktop.org/archive...st/003139.html

Wouldn't it be better to do this:

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 20c353c..31a09cd 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -977,24 +977,25 @@ static enum drm_connector_status radeon_dp_detect(struct drm_connector *connecto
 	struct radeon_connector *radeon_connector = to_radeon_connector(connector);
 	enum drm_connector_status ret = connector_status_disconnected;
 	struct radeon_connector_atom_dig *radeon_dig_connector = radeon_connector->con_priv;
-	u8 sink_type;
 
 	if (radeon_connector->edid) {
 		kfree(radeon_connector->edid);
 		radeon_connector->edid = NULL;
 	}
 
-	sink_type = radeon_dp_getsinktype(radeon_connector);
-	if ((sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
-	    (sink_type == CONNECTOR_OBJECT_ID_eDP)) {
-		if (radeon_dp_getdpcd(radeon_connector)) {
-			radeon_dig_connector->dp_sink_type = sink_type;
+	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+		/* eDP is always DP */
+		radeon_dig_connector->dp_sink_type = CONNECTOR_OBJECT_ID_DISPLAYPORT;
+		if (radeon_dp_getdpcd(radeon_connector))
 			ret = connector_status_connected;
-		}
 	} else {
-		if (radeon_ddc_probe(radeon_connector)) {
-			radeon_dig_connector->dp_sink_type = sink_type;
-			ret = connector_status_connected;
+		radeon_dig_connector->dp_sink_type = radeon_dp_getsinktype(radeon_connector);
+		if (radeon_dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) {
+			if (radeon_dp_getdpcd(radeon_connector))
+				ret = connector_status_connected;
+			else {
+				radeon_dig_connector->dp_sink_type = CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D;
+				if (radeon_ddc_probe(radeon_connector))
+					ret = connector_status_connected;
+			}
+		} else {
+			if (radeon_ddc_probe(radeon_connector))
+				ret = connector_status_connected;
 		}
 	}

It wouldn't break anything since we already know that the DP CAN'T work, but would leave it in a state where it would work with certain boards that are wired wrong by at least setting a sensible default state.

I know it is a workaround for one special case defect, but I wonder how many people are suffering with this (or similar) defects and are resigned to it being broken?

I also note that there are quite a number of workarounds elsewhere that deal with specific board defects, i.e. in radeon_atombios.c function radeon_atom_apply_quirks(), so it wouldn't even be unprecedented to add a workaround for a specific defect.

In this case though, the workaround would compensate for a class of defects that *could* be present on ANY DP board where the OEM didn't properly plan for supporting DP++.

[droidhacker]

I'm fairly certain that I found some nastys in drivers/gpu/drm/drm_modes.c

In the function drm_cvt_mode(), when parameter "reduced" is set to TRUE, the hsync_start and hsync_end values calculated are... wrong, and the vsync_start and vsync_end values aren't calculated at all.

This is when compared to the values calculated by the "cvt" command, i.e.
cvt -r 1920 1200
# 1920x1200 59.95 Hz (CVT 2.30MA-R) hsync: 74.04 kHz; pclk: 154.00 MHz
Modeline "1920x1200R" 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync

The values generated by drm_cvt_mode(dev,1920,1200,60,true,false,false) are:
154.00 1920 32 32 2080 1200 0 0 1235 +hsync -vsync

[droidhacker]

For anyone interested, for now (might look at the cvt algo later), I've jigged in my mode like this;

static int radeon_dp_get_modes(struct drm_connector *connector)
{
	struct radeon_connector *radeon_connector = to_radeon_connector(connector);
	int ret;
	struct drm_display_mode *mode = NULL;
	struct drm_device *dev = radeon_connector->base.dev;

	ret = radeon_ddc_get_modes(radeon_connector);
	//mode = drm_cvt_mode(dev, 1920, 1200, 60, true, false, false);
	if (mode = drm_mode_create(dev)){
		mode->hdisplay=1920;
		mode->vdisplay=1200;
		mode->vtotal=1235;
		mode->htotal=2080;
		mode->hsync_end=2000;
		mode->hsync_start=1968;
		mode->vsync_start=1203;
		mode->vsync_end=1209;
		mode->clock=154000;
		drm_mode_set_name(mode);
		mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC);
	}

	drm_mode_probed_add(connector, mode);
	return ret;
}

[agd5f]

I'm fairly certain that I found some nastys in drivers/gpu/drm/drm_modes.c

In the function drm_cvt_mode(), when parameter "reduced" is set to TRUE, the hsync_start and hsync_end values calculated are... wrong, and the vsync_start and vsync_end values aren't calculated at all.

This is when compared to the values calculated by the "cvt" command, i.e.
cvt -r 1920 1200
# 1920x1200 59.95 Hz (CVT 2.30MA-R) hsync: 74.04 kHz; pclk: 154.00 MHz
Modeline "1920x1200R" 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync

The values generated by drm_cvt_mode(dev,1920,1200,60,true,false,false) are:
154.00 1920 32 32 2080 1200 0 0 1235 +hsync -vsync

That should be fixed. Please file a bug at http://bugzilla.kernel.org or https://bugs.freedesktop.org

[droidhacker]

That should be fixed. Please file a bug at http://bugzilla.kernel.org or https://bugs.freedesktop.org

https://bugzilla.kernel.org/show_bug.cgi?id=16651

[droidhacker]

Well, that bug's been squashed.
http://lists.freedesktop.org/archive...st/003223.html