Or maybe 'D'? I'd at least think DisplayPort was a digital output.
Announcement
Collapse
No announcement yet.
890GX/HD4290 dual display question
Collapse
X
-
Originally posted by droidhacker View PostI 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
Originally posted by droidhacker View PostIs 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?
Comment
-
Originally posted by agd5f View PostYeah, I think that should do it.
Wouldn't it be better to do this:
Code: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; [b]+ else { + radeon_dig_connector->dp_sink_type = CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D; + if (radeon_ddc_probe(radeon_connector)) + ret = connector_status_connected; + }[/b] + } else { + if (radeon_ddc_probe(radeon_connector)) + ret = connector_status_connected; } }
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++.
Comment
-
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
Comment
-
For anyone interested, for now (might look at the cvt algo later), I've jigged in my mode like this;
Code: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; }
Comment
-
Originally posted by droidhacker View PostI'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
Comment
-
Originally posted by agd5f View PostThat should be fixed. Please file a bug at http://bugzilla.kernel.org or https://bugs.freedesktop.org
Comment
Comment