[Intel-gfx] More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter <thor at math.tu-berlin.de> 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:
>  [<c12f8c44>] ? dump_stack+0xa/0x13
>  [<c1033def>] ? warn_slowpath_common+0x7f/0xb0
>  [<f8a81ffa>] ? assert_cursor.constprop.68+0xba/0xc0 [i915]
>  [<f8a81ffa>] ? assert_cursor.constprop.68+0xba/0xc0 [i915]
>  [<c1033eb3>] ? warn_slowpath_fmt+0x33/0x40
>  [<f8a81ffa>] ? assert_cursor.constprop.68+0xba/0xc0 [i915]
>  [<f8a83b90>] ? intel_disable_pipe+0x30/0xb0 [i915]
>  [<f8a8491a>] ? i9xx_crtc_disable+0xca/0x2f0 [i915]
>  [<f8a8b25e>] ? __intel_set_mode+0x7ae/0x13b0 [i915]
>  [<f8a8e1f3>] ? intel_set_mode+0x23/0x40 [i915]
>  [<f8a8e9bc>] ? intel_crtc_set_config+0x7ac/0x9d0 [i915]
>  [<f802fe33>] ? drm_mode_set_config_internal+0x43/0xb0 [drm]
>  [<f81386a5>] ? drm_fb_helper_set_par+0x45/0xac [drm_kms_helper]
>  [<c11a7976>] ? fb_set_var+0x1a6/0x420
>  [<c10eec6e>] ? __find_get_block+0x9e/0x160
>  [<c11b56e0>] ? fbcon_blank+0x290/0x2d0
>  [<c1203848>] ? do_unblank_screen+0x98/0x1b0
>  [<c1201acd>] ? notify_update+0x1d/0x30
>  [<c11faa12>] ? complete_change_console+0x52/0xe0
>  [<c11fbba4>] ? vt_ioctl+0x1104/0x1220
>  [<f802a1d0>] ? drm_setmaster_ioctl+0xe0/0xe0 [drm]
>  [<c11faaa0>] ? complete_change_console+0xe0/0xe0
>  [<c11f17da>] ? tty_ioctl+0x21a/0x9a0
>  [<c10adb12>] ? do_wp_page.isra.92+0x2a2/0x650
>  [<c10af428>] ? handle_mm_fault+0x318/0x610
>  [<c11f15c0>] ? no_tty+0x20/0x20
>  [<c10d66ac>] ? do_vfs_ioctl+0x7c/0x550
>  [<c102d221>] ? __do_page_fault+0x1b1/0x490
>  [<c10c7d17>] ? vfs_write+0x137/0x1b0
>  [<c10d6bc6>] ? SyS_ioctl+0x46/0x80
>  [<c12fc19e>] ? 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... */
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch