Last known good: 3.4.4 First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Dmesg from 3.5.0: http://mrutecki.pl/download/kernel/3.5/swinka/dmesg-3.5.0.txt
Dmesg from 3.4.4: http://mrutecki.pl/download/kernel/3.5/swinka/dmesg-3.4.4.txt
Config 3.5.0: http://mrutecki.pl/download/kernel/3.5/swinka/config-3.5.0
lspci: http://mrutecki.pl/download/kernel/3.5/swinka/lspci.txt
Regards
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
Last known good: 3.4.4 First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose for both kernels? Also, please boot with drm.debug=0xe added to your kernel cmdline and grab the dmesg (again for both kernels).
Thanks, Daniel
Dmesg from 3.5.0: http://mrutecki.pl/download/kernel/3.5/swinka/dmesg-3.5.0.txt
Dmesg from 3.4.4: http://mrutecki.pl/download/kernel/3.5/swinka/dmesg-3.4.4.txt
Config 3.5.0: http://mrutecki.pl/download/kernel/3.5/swinka/config-3.5.0
lspci: http://mrutecki.pl/download/kernel/3.5/swinka/lspci.txt
Regards
Maciej Rutecki http://www.mrutecki.pl _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
Last known good: 3.4.4 First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose for both kernels? Also, please boot with drm.debug=0xe added to your kernel cmdline and grab the dmesg (again for both kernels).
Thanks for the ansfer.
Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
http://mrutecki.pl/download/kernel/3.5/swinka/debug/
Regards
On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
Last known good: 3.4.4 First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose for both kernels? Also, please boot with drm.debug=0xe added to your kernel cmdline and grab the dmesg (again for both kernels).
Thanks for the ansfer.
Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
Can you please test this quick hack:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -405,7 +405,7 @@ clear_err: * timing out seems to happen when there _is_ a ddc chip present, but * it's slow responding and only answers on the 2nd retry. */ - ret = -ENXIO; + ret = 0; if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10)) { DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
Thanks, Daniel
On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
Last known good: 3.4.4 First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose for both kernels? Also, please boot with drm.debug=0xe added to your kernel cmdline and grab the dmesg (again for both kernels).
Thanks for the ansfer.
Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
Can you please test this quick hack:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -405,7 +405,7 @@ clear_err: * timing out seems to happen when there _is_ a ddc chip present, but * it's slow responding and only answers on the 2nd retry. */
- ret = -ENXIO;
- ret = 0; if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10)) { DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
Thanks, Daniel
Still the same.
PS. Unfortunately, this afternoon I have small a surgical operation and further tests will be possible only after 2-3 days.
Regards
On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki maciej.rutecki@gmail.com wrote:
On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
Last known good: 3.4.4 First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose for both kernels? Also, please boot with drm.debug=0xe added to your kernel cmdline and grab the dmesg (again for both kernels).
Thanks for the ansfer.
Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
Can you please test this quick hack:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -405,7 +405,7 @@ clear_err: * timing out seems to happen when there _is_ a ddc chip present, but * it's slow responding and only answers on the 2nd retry. */
ret = -ENXIO;
ret = 0; if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10)) { DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
Thanks, Daniel
Still the same.
Hm, can you attach the dmesg again (with drm.debug=0xe)? If I haven't botched up something, we should now retry at least the ddc transfer ... -Daniel
PS. Unfortunately, this afternoon I have small a surgical operation and further tests will be possible only after 2-3 days.
Regards
Maciej Rutecki http://www.mrutecki.pl
On Wed, Jul 25, 2012 at 01:55:59PM +0200, Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki maciej.rutecki@gmail.com wrote:
On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
Last known good: 3.4.4 First bad: 3.5.0
When booting 3.5.0 resolution (in console, and after in KDE) is set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose for both kernels? Also, please boot with drm.debug=0xe added to your kernel cmdline and grab the dmesg (again for both kernels).
Thanks for the ansfer.
Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
Can you please test this quick hack:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -405,7 +405,7 @@ clear_err: * timing out seems to happen when there _is_ a ddc chip present, but * it's slow responding and only answers on the 2nd retry. */
ret = -ENXIO;
ret = 0; if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10)) { DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
Thanks, Daniel
Still the same.
Hm, can you attach the dmesg again (with drm.debug=0xe)? If I haven't botched up something, we should now retry at least the ddc transfer ...
Also, another little snippet for you to test. Fyi I'll be on vacation next week, so final patch (this one here should really work) might take a notch longer.
Yours, Daniel -- diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index bc5e2c9..85eca1c 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -338,6 +338,7 @@ static bool intel_crt_detect_ddc(struct drm_connector *connector) BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin); + intel_gmbus_force_bit(i2c, true); edid = drm_get_edid(connector, i2c);
if (edid) { @@ -546,12 +547,14 @@ static int intel_crt_get_modes(struct drm_connector *connector) struct i2c_adapter *i2c;
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin); + intel_gmbus_force_bit(i2c, true); ret = intel_ddc_get_modes(connector, i2c); if (ret || !IS_G4X(dev)) return ret;
/* Try to probe digital port for output in DVI-I -> VGA mode. */ i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB); + intel_gmbus_force_bit(i2c, true); return intel_ddc_get_modes(connector, i2c); }
On czwartek, 26 lipca 2012 o 14:38:28 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 01:55:59PM +0200, Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
maciej.rutecki@gmail.com wrote:
On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote: > Last known good: 3.4.4 > First bad: 3.5.0 > > When booting 3.5.0 resolution (in console, and after in KDE) is > set to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
Can you please attach the output of xrandr --verbose for both kernels? Also, please boot with drm.debug=0xe added to your kernel cmdline and grab the dmesg (again for both kernels).
Thanks for the ansfer.
Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
Can you please test this quick hack:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -405,7 +405,7 @@ clear_err: * timing out seems to happen when there _is_ a ddc chip present, but * it's slow responding and only answers on the 2nd retry. */
ret = -ENXIO;
ret = 0; if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10)) { DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
Thanks, Daniel
Still the same.
Hm, can you attach the dmesg again (with drm.debug=0xe)? If I haven't botched up something, we should now retry at least the ddc transfer ...
Also, another little snippet for you to test. Fyi I'll be on vacation next week, so final patch (this one here should really work) might take a notch longer.
Yours, Daniel
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index bc5e2c9..85eca1c 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -338,6 +338,7 @@ static bool intel_crt_detect_ddc(struct drm_connector *connector) BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
intel_gmbus_force_bit(i2c, true); edid = drm_get_edid(connector, i2c);
if (edid) {
@@ -546,12 +547,14 @@ static int intel_crt_get_modes(struct drm_connector *connector) struct i2c_adapter *i2c;
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
intel_gmbus_force_bit(i2c, true); ret = intel_ddc_get_modes(connector, i2c); if (ret || !IS_G4X(dev)) return ret;
/* Try to probe digital port for output in DVI-I -> VGA mode. */ i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
intel_gmbus_force_bit(i2c, true); return intel_ddc_get_modes(connector, i2c);
}
I have little problem with the patch: $ patch -p1 < /tmp/latka.patch patching file drivers/gpu/drm/i915/intel_crt.c Hunk #1 FAILED at 338. patch unexpectedly ends in middle of line Hunk #2 succeeded at 498 with fuzz 2 (offset -48 lines). 1 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_crt.c.rej
But I add "intel_gmbus_force_bit(i2c, true);" manually and now resolution is OK. Thanks for help.
PS. I also will be in vacation between 4-19 August, so my test may take longer.
Regards
Alex, Maciej, please test the following to see if it fixes the issue [1], thanks.
BR, Jani.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
Jani Nikula (2): drm/i915: extract connector update from intel_ddc_get_modes() for reuse drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
drivers/gpu/drm/i915/intel_crt.c | 36 +++++++++++++++++++++++++++++++++--- drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_modes.c | 31 ++++++++++++++++++++++--------- 3 files changed, 57 insertions(+), 12 deletions(-)
Refactor the connector update part of intel_ddc_get_modes() into a separate intel_connector_update_modes() function for reuse. No functional changes.
Signed-off-by: Jani Nikula jani.nikula@intel.com --- drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_modes.c | 31 ++++++++++++++++++++++--------- 2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 13f0467..8a224ca 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -357,6 +357,8 @@ struct intel_fbc_work { int interval; };
+int intel_connector_update_modes(struct drm_connector *connector, + struct edid *edid); int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
extern void intel_attach_force_audio_property(struct drm_connector *connector); diff --git a/drivers/gpu/drm/i915/intel_modes.c b/drivers/gpu/drm/i915/intel_modes.c index 45848b9..29b7259 100644 --- a/drivers/gpu/drm/i915/intel_modes.c +++ b/drivers/gpu/drm/i915/intel_modes.c @@ -33,6 +33,25 @@ #include "i915_drv.h"
/** + * intel_connector_update_modes - update connector from edid + * @connector: DRM connector device to use + * @edid: previously read EDID information + */ +int intel_connector_update_modes(struct drm_connector *connector, + struct edid *edid) +{ + int ret; + + drm_mode_connector_update_edid_property(connector, edid); + ret = drm_add_edid_modes(connector, edid); + drm_edid_to_eld(connector, edid); + connector->display_info.raw_edid = NULL; + kfree(edid); + + return ret; +} + +/** * intel_ddc_get_modes - get modelist from monitor * @connector: DRM connector device to use * @adapter: i2c adapter @@ -43,18 +62,12 @@ int intel_ddc_get_modes(struct drm_connector *connector, struct i2c_adapter *adapter) { struct edid *edid; - int ret = 0;
edid = drm_get_edid(connector, adapter); - if (edid) { - drm_mode_connector_update_edid_property(connector, edid); - ret = drm_add_edid_modes(connector, edid); - drm_edid_to_eld(connector, edid); - connector->display_info.raw_edid = NULL; - kfree(edid); - } + if (!edid) + return 0;
- return ret; + return intel_connector_update_modes(connector, edid); }
static const struct drm_prop_enum_list force_audio_names[] = {
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6d235bd465309e12f4c56ea16e71111 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Fri Mar 2 19:38:30 2012 +0100
drm/i915: enable gmbus on gen2
Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging fallback to CRT EDID reads.
LKML-Reference: 201207251020.47637.maciej.rutecki@gmail.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881 Signed-off-by: Jani Nikula jani.nikula@intel.com --- drivers/gpu/drm/i915/intel_crt.c | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index bc5e2c9..80bf311 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -328,6 +328,36 @@ static bool intel_crt_detect_hotplug(struct drm_connector *connector) return ret; }
+static struct edid *intel_crt_get_edid(struct drm_connector *connector, + struct i2c_adapter *i2c) +{ + struct edid *edid; + + edid = drm_get_edid(connector, i2c); + + if (!edid && !intel_gmbus_is_forced_bit(i2c)) { + DRM_DEBUG_KMS("CRT GMBUS EDID read failed, retry using GPIO bit-banging\n"); + intel_gmbus_force_bit(i2c, true); + edid = drm_get_edid(connector, i2c); + intel_gmbus_force_bit(i2c, false); + } + + return edid; +} + +/* local version of intel_ddc_get_modes() to use intel_crt_get_edid() */ +static int intel_crt_ddc_get_modes(struct drm_connector *connector, + struct i2c_adapter *adapter) +{ + struct edid *edid; + + edid = intel_crt_get_edid(connector, adapter); + if (!edid) + return 0; + + return intel_connector_update_modes(connector, edid); +} + static bool intel_crt_detect_ddc(struct drm_connector *connector) { struct intel_crt *crt = intel_attached_crt(connector); @@ -338,7 +368,7 @@ static bool intel_crt_detect_ddc(struct drm_connector *connector) BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin); - edid = drm_get_edid(connector, i2c); + edid = intel_crt_get_edid(connector, i2c);
if (edid) { bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL; @@ -546,13 +576,13 @@ static int intel_crt_get_modes(struct drm_connector *connector) struct i2c_adapter *i2c;
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin); - ret = intel_ddc_get_modes(connector, i2c); + ret = intel_crt_ddc_get_modes(connector, i2c); if (ret || !IS_G4X(dev)) return ret;
/* Try to probe digital port for output in DVI-I -> VGA mode. */ i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB); - return intel_ddc_get_modes(connector, i2c); + return intel_crt_ddc_get_modes(connector, i2c); }
static int intel_crt_set_property(struct drm_connector *connector,
On Mon, Aug 13, 2012 at 01:22:35PM +0300, Jani Nikula wrote:
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6d235bd465309e12f4c56ea16e71111 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Fri Mar 2 19:38:30 2012 +0100
drm/i915: enable gmbus on gen2
Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging fallback to CRT EDID reads.
LKML-Reference: 201207251020.47637.maciej.rutecki@gmail.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881 Signed-off-by: Jani Nikula jani.nikula@intel.com
Patches applied to -fixes with the tested-by result from the bug report. I've also put a cc: stable on both of them, since the regression is already in 3.4.
Thanks, Daniel
dri-devel@lists.freedesktop.org