From: Maciej Rutecki <maciej.rutecki@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [REGRESSION] [KMS] [INTEL] Wrong resolution in console and XWindow
Date: Fri, 27 Jul 2012 13:46:49 +0200 [thread overview]
Message-ID: <201207271346.49259.maciej.rutecki@gmail.com> (raw)
In-Reply-To: <20120726123828.GE5326@phenom.ffwll.local>
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
> > >> >
> > >> > http://mrutecki.pl/download/kernel/3.5/swinka/debug/
> > >>
> > >> 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
--
Maciej Rutecki
http://www.mrutecki.pl
next prev parent reply other threads:[~2012-07-27 11:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 8:20 [REGRESSION] [KMS] [INTEL] Wrong resolution in console and XWindow Maciej Rutecki
2012-07-25 8:29 ` Daniel Vetter
2012-07-25 8:54 ` Maciej Rutecki
2012-07-25 9:29 ` Daniel Vetter
2012-07-25 10:57 ` Maciej Rutecki
2012-07-25 11:55 ` Daniel Vetter
2012-07-26 12:38 ` Daniel Vetter
2012-07-27 11:46 ` Maciej Rutecki [this message]
2012-08-13 10:22 ` [PATCH 0/2] GMBUS EDID read bit-banging fallback Jani Nikula
2012-08-13 10:22 ` [PATCH 1/2] drm/i915: extract connector update from intel_ddc_get_modes() for reuse Jani Nikula
2012-08-13 10:22 ` [PATCH 2/2] drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads Jani Nikula
2012-08-16 14:35 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201207271346.49259.maciej.rutecki@gmail.com \
--to=maciej.rutecki@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.