890GX/HD4290 dual display question

[agd5f]

DP uses aux, non-DP uses plain i2c. IIRC, they both use the same pins on the connector, but I'm not sure if the oem wired the i2c gpios to the connector; they might have just wired the aux line.

[droidhacker]

The document you linked about the 780 suggests that both actually use the same pins on the 780 itself and are configured to either i2c or aux depending on what is there, i.e. discovered through cable adapter detect and/or vbios... which means that if the aux line is connected, so must be the i2c...

See http://developer.amd.com/assets/4573...s_pub_3.10.pdf table 3-12 on page 3-11.


But yeah, that driver hack is definitely what I was getting at. Thank you very much for that. Tonight looks like another fun-filled evening of hacking

[agd5f]

Ah, indeed. I wonder if the oem hooked up the pins at all since neither fglrx nor the open source driver are able to get an EDID from any monitor (DP or otherwise) on that connector.

[droidhacker]

Ah, indeed. I wonder if the oem hooked up the pins at all since neither fglrx nor the open source driver are able to get an EDID from any monitor (DP or otherwise) on that connector.

I have a crazy feeling that my active adapter is a POS. It ties the Cable Adapter Detect line to DP power return, i.e. high, so I have a feeling that it is some kind of weird hackish thing. An actual DP monitor is supposed to tie Cable Adapter Detect low.

In any case though, fglrx *does* claim to be finding a monitor and activating it... just that nothing comes out of it. Presumably because it is trying to activate a DP monitor when a DVI is actually present.

[droidhacker]

I have a crazy feeling that my active adapter is a POS. It ties the Cable Adapter Detect line to DP power return, i.e. high, so I have a feeling that it is some kind of weird hackish thing. An actual DP monitor is supposed to tie Cable Adapter Detect low.

In any case though, fglrx *does* claim to be finding a monitor and activating it... just that nothing comes out of it. Presumably because it is trying to activate a DP monitor when a DVI is actually present.

... another thought has occurred to me regarding my active adapter. It may be trying to be smart -- only go active if a DVI-DL is connected, otherwise go passive.

[droidhacker]

you'll have to hack the driver directly. Something like:

--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -998,6 +998,9 @@ static enum drm_connector_status radeon_dp_detect(struct drm_connector *connecto
}
}

+ radeon_dig_connector->dp_sink_type = CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D;
+ ret = connector_status_connected;
+
return ret;
}

And this is why open source is better than closed source
Mainboard maker screwed up the circuit, said "it can't be done", and yet its doing what they say it can't do. DP-DVI passive adapter WORKING!!!

Alex: You gotta tell me where to send the beer and what brand.

[agd5f]

Glad to hear you got it working

[droidhacker]

Thinking about this hack a little more....
Rather than the hack you offered, what if up just a little higher in the same function, the line

sink_type = radeon_dp_...
is changed to
sink_type = CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D;
??

Then it should do the DDC probe and hopefully pull an EDID, right?

And what do you think about the feasibility of adding a force-override module argument, i.e. something like radeon.forceDPDVI=1, and an "if" around the sink_type line? Would it be possible to get something like this into the kernel? Or is it too fringe of a case being that it is required only to compensate for a defect?

[droidhacker]

Further thought....
It may be possible to detect the display type automatically without.... asking.

i.e.

	sink_type = radeon_dp_getsinktype(radeon_connector);
	if (((sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
	    (sink_type == CONNECTOR_OBJECT_ID_eDP)) && (radeon_dp_getdpcd(radeon_connector))) {
		radeon_dig_connector->dp_sink_type = sink_type;
		ret = connector_status_connected;
	} else {
		sink_type = CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D;
		radeon_i2c_do_lock(radeon_connector->ddc_bus, 1);
		if (radeon_ddc_probe(radeon_connector)) {
			radeon_dig_connector->dp_sink_type = sink_type;
			ret = connector_status_connected;
		}
		radeon_i2c_do_lock(radeon_connector->ddc_bus, 0);
	}

Would that work? Or am I thinking of something crazy and/or dangerous that is bound to blow up in my face?

[agd5f]

You probably don't need to force the sink type; I just did that to be sure it wasn't getting mis-detected as DP. You'll need to add some debugging printks and see what radeon_dp_getsinktype() returns in your case.

You also don't need the radeon_i2c_do_lock() anymore. that's taken care of the i2c core now (assuming you have a newish kernel, 2.6.33 or 34 I think).

The current code as is should work, however, it returns disconnected if it can't get an edid, and for whatever reason, it can't get an edid on your board (that's probably the line that wasn't connected). That's why you have to force ret = connector_status_connected;

The current logic is:

sink = get_sinktype();
if (sink is DP) {
if (get_dpcd) {
//DP is connected
}
} else {
if (get_edid) {
// DVI/HDMI is connected
}
}