[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hfws1whq8.wl%tiwai@suse.de>
Date: Sun, 06 Feb 2011 12:00:15 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Jeff Chua <jeff.chua.linux@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Chris Wilson <chris@...is-wilson.co.uk>,
Len Brown <lenb@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_
At Sun, 6 Feb 2011 09:50:51 +0800,
Jeff Chua wrote:
>
> On Sun, Feb 6, 2011 at 2:24 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> >> The suspend monster is back! The suspend-to-ram is fine, but upon
> >> resume, screen is blank. Haven't bisected in case someone has also
> >> done so.
> >
> > BTW, please don't reply to messages containing patches with reports of problems
> > that aren't caused by those patches. It's confusing at best and at worst it
> > may result in the patches being rejected.
>
> Sorry. New subject now:)
>
>
> On Sun, Feb 6, 2011 at 2:51 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >> It's very recent. ... between commit
> >> 831d52bc153971b70e64eccfbed2b232394f22f8 and
> >> 44f2c5c841da1b1e0864d768197ab1497b5c2cc1.
> >
> > Hmm. It's almost certainly one of the DRI patches, but which one? I
> > think bisection is the only way to figure it out. It shouldn't be too
> > bad, since there's only 120 commits in that range.
> >
> > In fact, you can almost certainly just bisect from 89840966c579 to
> > bb5b583b5279, which is just 31 commits and should get you bisected in
> > just five tries or so.
>
> Yea, I've just done that. It came down to the following commit.
> Reverting it solves the problem. I've gone thru a few cycles, and
> notebook still survives.
Hrm, what is the symptom? I couldn't find it because you cut off the
thread, and it's not cited.
The commit you mentioned just adds an interface, and the the callbacks
aren't defined. The real change is either in
commit f3269058e7a80083dcdf89698bfcd1a6c6f8fd12
drm/i915/crt: Force the initial probe after reset
or
commit 5d1d0cc87fc0887921993ea0742932e0c8adeda0
drm/i915: Reset crtc after resume
Also the fix might interact with
commit 811aaa55ba21ab37407018cfc01770d6b037d3fb
drm: Only set DPMS ON when actually configuring a mode
thanks,
Takashi
>
> Thanks,
> Jeff
>
>
> commit 500f7147cf5bafd139056d521536b10c2bc2e154
> Author: Chris Wilson <chris@...is-wilson.co.uk>
> Date: Mon Jan 24 15:14:41 2011 +0000
>
> drm/i915: Reset state after a GPU reset or resume
>
> Call drm_mode_config_reset() after an invalidation event to restore any
> cached state to unknown.
>
> Tested-by: Takashi Iwai <tiwai@...e.de>
> Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists