From patchwork Sun Nov 3 21:18:14 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 3133881 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 747859F3C4 for ; Sun, 3 Nov 2013 21:18:00 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5886920411 for ; Sun, 3 Nov 2013 21:17:59 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id D9E0A2039C for ; Sun, 3 Nov 2013 21:17:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D92AFF0D41; Sun, 3 Nov 2013 13:17:55 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by gabe.freedesktop.org (Postfix) with ESMTP id 802C4F0D41 for ; Sun, 3 Nov 2013 13:17:48 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id c1so350545eek.1 for ; Sun, 03 Nov 2013 13:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:sender:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=OkIWQp4NuDCNv3UDBRjOMjznOtQ88xtaAVdm2hEPnlk=; b=TFoRSPPEFe1Cpp2tGhLyvYixjB83PZXY7Dy30EXidx23i/gMyZPiMP+5sUfAkCNDL3 0xTNMq7szWvXOVMPf6iuPk3yd6CQnx+YAqxUD8o73QuIuY5nc67Hn7RoZ5qm3kd38CV1 OABN9u4KywqviQts/SwU1XdBDcD4bjaSQJxsE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:sender:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=OkIWQp4NuDCNv3UDBRjOMjznOtQ88xtaAVdm2hEPnlk=; b=So393YUDR7lhpj1V8CDKDkwMRDWRVdKqhbOGmgxKksQxiV+eiJjFvkaxirgteGqZJn ktAfFxaMjN+rmGElfT3mAfI3qkLXb5ZGbYG/y7SAA1D6MGBtRM0mNu66X6dIUNizUvN3 1YrD7z2OReHQsmuRCA+MQQe3oILfZIorjGsTlTsILzNqyIk2pYzRgsaYLQOk5XXXsZAr ZL1m5BDhxNcQIw4o9OsyGEiJORfE2rYlHctW1KiU9LgLWyD+799D9Mvv6PFogKUTt9/i SZ6n2146/I44ABhmWMCUGhjQrhgr0Hnua5KjuxIVBeNJD8A6cr0tA6hzdLn7VEJd4k0b sGgg== X-Gm-Message-State: ALoCoQnPnS3fuOzxC6/MrVgEv1FoFknbPj/5UAddodAXObtgma9YqXI2hohUHcdGt/r7arOjSWNL X-Received: by 10.14.216.68 with SMTP id f44mr14763042eep.6.1383513465058; Sun, 03 Nov 2013 13:17:45 -0800 (PST) Received: from phenom.ffwll.local (178-83-130-250.dynamic.hispeed.ch. [178.83.130.250]) by mx.google.com with ESMTPSA id a6sm37910098eei.10.2013.11.03.13.17.43 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 03 Nov 2013 13:17:44 -0800 (PST) Date: Sun, 3 Nov 2013 22:18:14 +0100 From: Daniel Vetter To: Thomas Richter Message-ID: <20131103211814.GC4167@phenom.ffwll.local> References: <52768009.7070905@math.tu-berlin.de> <20131103171208.GA4167@phenom.ffwll.local> <19544_1383498802_52768431_19544_2610_1_20131103171348.GB4167@phenom.ffwll.local> <52769D39.5070501@math.tu-berlin.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <52769D39.5070501@math.tu-berlin.de> Received: by 10.42.115.9 with HTTP; Sun, 3 Nov 2013 13:00:17 -0800 (PST) X-Originating-IP: [178.83.130.250] User-Agent: Mutt/1.5.21 (2010-09-15) Cc: intel-gfx Subject: Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter wrote: > On 03.11.2013 18:13, Daniel Vetter wrote: >>> >>> Have you tried my patch to reorder the dvo sequence a bit? That /should/ >>> get all these things right: >>> >>> http://www.spinics.net/lists/intel-gfx/msg34349.html >> >> There's also a follow-up patch for you to test: >> >> >> http://www.spinics.net/lists/intel-gfx/msg34350.html >> >> That would prove that the first patch does indeed work. Note that patch 1 >> in this series is already merged. > > Thanks, I tried. Actually, this worked fairly (but not perfectly) well. I no > longer get a "stuck DVO" as I did before, i.e. the "re-enable" logic is not > triggered anymore. However, I do get (occasionally) a kernel-oops: That's just a warning, not an oops ... > > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 2311 at drivers/gpu/drm/i915/intel_display.c:1098 > assert_cursor.constprop.68+0xba/0xc0 [i915]() > cursor on pipe A assertion failure (expected off, current on) > Modules linked in: cpufreq_stats binfmt_misc michael_mic arc4 ecb > lib80211_crypt_tkip lib80211_crypt_ccmp fuse nfsd exportfs nfs_acl nfs lockd > fscache sunrpc loop firewire_sbp2 hostap_cs hostap snd_intel8x0 > snd_ac97_codec ac97_bus lib80211 snd_pcm i915 snd_page_alloc snd_seq > snd_seq_device snd_timer psmouse snd pcmcia apanel input_polldev soundcore > yenta_socket pcmcia_rsrc pcmcia_core lpc_ich i2c_i801 mfd_core pcspkr > i2c_algo_bit rng_core serio_raw evdev drm_kms_helper drm fujitsu_laptop > led_class intel_agp intel_gtt agpgart i2c_core video ac button hid_generic > usbhid hid sg sr_mod cdrom firewire_ohci firewire_core crc_itu_t 8139too > 8139cp mii uhci_hcd usbcore usb_common > CPU: 0 PID: 2311 Comm: Xorg Tainted: G W 3.12.0-rc7+ #13 > Hardware name: FUJITSU SIEMENS LIFEBOOK S Series/FJNB159, BIOS Version 1.06 > 07/02/2002 > c12f8c44 c1033def f8ad3990 f6adfab0 00000907 f8ad25d8 0000044a f8a81ffa > f8a81ffa f5ca8000 00000041 00000000 f5ca8000 c1033eb3 00000009 f6adfa98 > f8ad3990 f6adfab0 f8a81ffa f8ad25d8 0000044a f8ad3990 00000041 f8adb9a0 > Call Trace: > [] ? dump_stack+0xa/0x13 > [] ? warn_slowpath_common+0x7f/0xb0 > [] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > [] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > [] ? warn_slowpath_fmt+0x33/0x40 > [] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > [] ? intel_disable_pipe+0x30/0xb0 [i915] > [] ? i9xx_crtc_disable+0xca/0x2f0 [i915] > [] ? __intel_set_mode+0x7ae/0x13b0 [i915] > [] ? intel_set_mode+0x23/0x40 [i915] > [] ? intel_crtc_set_config+0x7ac/0x9d0 [i915] > [] ? drm_mode_set_config_internal+0x43/0xb0 [drm] > [] ? drm_fb_helper_set_par+0x45/0xac [drm_kms_helper] > [] ? fb_set_var+0x1a6/0x420 > [] ? __find_get_block+0x9e/0x160 > [] ? fbcon_blank+0x290/0x2d0 > [] ? do_unblank_screen+0x98/0x1b0 > [] ? notify_update+0x1d/0x30 > [] ? complete_change_console+0x52/0xe0 > [] ? vt_ioctl+0x1104/0x1220 > [] ? drm_setmaster_ioctl+0xe0/0xe0 [drm] > [] ? complete_change_console+0xe0/0xe0 > [] ? tty_ioctl+0x21a/0x9a0 > [] ? do_wp_page.isra.92+0x2a2/0x650 > [] ? handle_mm_fault+0x318/0x610 > [] ? no_tty+0x20/0x20 > [] ? do_vfs_ioctl+0x7c/0x550 > [] ? __do_page_fault+0x1b1/0x490 > [] ? vfs_write+0x137/0x1b0 > [] ? SyS_ioctl+0x46/0x80 > [] ? sysenter_do_call+0x12/0x26 > ---[ end trace 85d231d1072e932a ]--- > > If this happens, I get a black screen with only a cursor on it. Switching to > the console and back restores the screen. Hm, that would mean that the cursor is somehow stuck in the enabled state, despite that we've tried to disabled it very hard. Can you please try out the below patch? If this doesn't work please take not of the different WARNINGs you're hitting and whether it's always the same one with the same calltrace or something different. I think for now we should try to get the single monitor case working - I have a few theories for the dual-screen issues, but there's not much point working on them if the simple case doesn't work yet. Also I think I'll merge the two patches if they don't make things worse for you, imo it's the right approach and at least conceptually should be able to avoid all these retry loops. Thanks, Daniel diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f34252d134b6..04d2699f51b4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7123,7 +7123,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base) intel_crtc->cursor_visible = visible; } /* and commit changes on next vblank */ + POSTING_READ(CURCNTR(pipe)); I915_WRITE(CURBASE(pipe), base); + POSTING_READ(CURBASE(pipe)); } static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) @@ -7152,7 +7154,9 @@ static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) intel_crtc->cursor_visible = visible; } /* and commit changes on next vblank */ + POSTING_READ(CURCNTR_IVB(pipe)); I915_WRITE(CURBASE_IVB(pipe), base); + POSTING_READ(CURBASE_IVB(pipe)); } /* If no-part of the cursor is visible on the framebuffer, then the GPU may hang... */