Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753222Ab1BGIpT (ORCPT ); Mon, 7 Feb 2011 03:45:19 -0500 Received: from mail-iw0-f174.google.com ([209.85.214.174]:59879 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752954Ab1BGIpS convert rfc822-to-8bit (ORCPT ); Mon, 7 Feb 2011 03:45:18 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qWS7oJe34uJ9S3DSgXZZpitIgDjIBZ1X4JOBeBnLXNdzlpWBJ+LXzbkgvh4byalZZv 9jSXc+O8CBuCyCyxn1Ecyp5x3Tw/Q+TmZ1FloFLgcqzRkfS1sX5/ejbxz0kCQ8TcDOyp HM/vxmGYtc7PjSQ5ERnrxAjYhhx/2DMEZb+x4= MIME-Version: 1.0 In-Reply-To: References: <849307$bf0dak@azsmga001.ch.intel.com> Date: Mon, 7 Feb 2011 16:45:16 +0800 Message-ID: Subject: Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_ From: Jeff Chua To: Takashi Iwai Cc: Chris Wilson , Linus Torvalds , "Rafael J. Wysocki" , Len Brown , LKML Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2424 Lines: 60 On Mon, Feb 7, 2011 at 4:36 PM, Jeff Chua wrote: > On Mon, Feb 7, 2011 at 4:25 PM, Takashi Iwai wrote: >> At Mon, 7 Feb 2011 13:02:46 +0800, >> Jeff Chua wrote: >>> >>> On Mon, Feb 7, 2011 at 12:48 PM, Jeff Chua wrote: >>> > On Sun, Feb 6, 2011 at 11:27 PM, Chris Wilson wrote: >>> >> One last step: move contents of intel_crtc_reset() back to >>> >> intel_crtc_init() one by one. >>> >> >>> >> The active flag is my suspicion. I was thinking that we brought up the >>> >> outputs in a similar manner upon resume as upon initial boot. On >>> >> reflection, this is the not case. >>> >> >>> >> However, the first action we take inside modesetting is to disable the >>> >> outputs about to be reconfigured. So setting active should be the right >>> >> course of action so that cleanup any residual state from resume. >>> >> >>> >> So I am intrigued as to which line is the cause, and just where the >>> >> machine becomes unresponsive... >>> > >>> > It's this line causing the problem. >>> > >>> > intel_crtc->active = true; /* force the pipe off on setup_init_config */ >>> > >>> > >>> > When it's called before entering intel_crtc_reset(&intel_crtc->base), >>> > it works, but if called within the function, it doesn't work. Strange. >>> > Not sure whether is passing the correct value to to_intel_crtc(crtc)? >>> >>> I've added printk() below and the function returns a different value >>> of intel_crtc. >>> >>> >>> static void intel_crtc_reset(struct drm_crtc *crtc) >>> { >>> ? ? ? ? struct intel_crtc *intel_crtc = to_intel_crtc(crtc); >>> ? ? ? ? printk("intel_crtc %p\n", intel_crtc); ===> intel_crtc ffff8802349d1000 >>> >>> } >>> >>> printk("intel_crtc %p\n", intel_crtc); ===> intel_crtc ffff8802349d0000 >>> intel_crtc_reset(&intel_crtc->base); >> >> That's weird. ?Since base is the first member, both intel_crtc and crtc >> must be identical. > > In case I'm messing something up, here's my intel_display.c Why not just pass intel_crtc as in - static void intel_crtc_reset(struct drm_crtc *crtc) + static void intel_crtc_reset(struct intel_crtc *intel_crtc) Jeff. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/