More questions and patches for 835GM/ns2501 DVO

More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

Hi Daniel, dear intel experts,

again trying to get the old Fujitsu laptop to work. The problem with the 
latest drm-nightly built is that
the system again locks up - if the bios is configured to show an image 
only on the internal display and
nothing on the external VGA. If the bios is configured to "shared 
video", booting works fine.

This seems to be related to the problem that, apparently, the bios seems 
to prefer to connect the internal
display to pipe B and not pipe A, and hence during bootstrap just 
configuring the dpll for pipe A is not enough.

That being said, the following modifications for ns2501 will fix this:

struct ns2501_priv need to get a new field int pll_b. In enable_dvo(), 
the setting for the dpll_b needs to be
saved, too, and installed, too:
     I915_WRITE(_DPLL_A, 0xd0820000);
     I915_WRITE(_DPLL_B, 0xd0820000);

It is absolutely unnecessary to overwrite the DVOC register, this is 
configured fine. In "restore_dvo()", the dpll_b
configuration needs to be restored as well. The DVOC register need not 
to be touched. In fact, the current
enable_dvo() has a bug in so far as it saves the wrong register.

However, what is more stunning is how this bug is triggered. Actually, 
intel_display.c computes the dpll register
value correctly (as it seems), but __intel_set_mode() (around line 9356) 
is a bit strange:

First, it disables the crtcs, then sets the mode, and the enables the 
crtcs. Unfortunately, this cannot work with
with the ns2501 since a disabled PLL will block any communication with 
with the DVO. I tried to move the "enable"
call above the intel_crtc_mode_set(), but this did not work either. I do 
not know enough about the inner workings
of intel_display.c to fix this properly, but the problem seems to be 
exactly that: An incorrectly configured DPLL
disables the communication with the DVO, hence the need for the workaround.

Last, a question: All I can get with the current intel driver is a 
"shared display" between the internal and external
display. Is there any way (through xrandr) to get two different 
configurations such that the external monitor is
using one configuration feed through pipe A, and the internal display is 
feed through pipe B with another configuration?

And finally: As the internal display is only a 6 bit display, is there a 
way to enable dithering on the 835GM to avoid the banding artifacts?

Greetings,
     Thomas

Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote:
> Hi Daniel, dear intel experts,
> 
> again trying to get the old Fujitsu laptop to work. The problem with
> the latest drm-nightly built is that
> the system again locks up - if the bios is configured to show an
> image only on the internal display and
> nothing on the external VGA. If the bios is configured to "shared
> video", booting works fine.
> 
> This seems to be related to the problem that, apparently, the bios
> seems to prefer to connect the internal
> display to pipe B and not pipe A, and hence during bootstrap just
> configuring the dpll for pipe A is not enough.
> 
> That being said, the following modifications for ns2501 will fix this:
> 
> struct ns2501_priv need to get a new field int pll_b. In
> enable_dvo(), the setting for the dpll_b needs to be
> saved, too, and installed, too:
>     I915_WRITE(_DPLL_A, 0xd0820000);
>     I915_WRITE(_DPLL_B, 0xd0820000);
> 
> It is absolutely unnecessary to overwrite the DVOC register, this is
> configured fine. In "restore_dvo()", the dpll_b
> configuration needs to be restored as well. The DVOC register need
> not to be touched. In fact, the current
> enable_dvo() has a bug in so far as it saves the wrong register.
> 
> However, what is more stunning is how this bug is triggered.
> Actually, intel_display.c computes the dpll register
> value correctly (as it seems), but __intel_set_mode() (around line
> 9356) is a bit strange:
> 
> First, it disables the crtcs, then sets the mode, and the enables
> the crtcs. Unfortunately, this cannot work with
> with the ns2501 since a disabled PLL will block any communication
> with with the DVO. I tried to move the "enable"
> call above the intel_crtc_mode_set(), but this did not work either.
> I do not know enough about the inner workings
> of intel_display.c to fix this properly, but the problem seems to be
> exactly that: An incorrectly configured DPLL
> disables the communication with the DVO, hence the need for the workaround.

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

> Last, a question: All I can get with the current intel driver is a
> "shared display" between the internal and external
> display. Is there any way (through xrandr) to get two different
> configurations such that the external monitor is
> using one configuration feed through pipe A, and the internal
> display is feed through pipe B with another configuration?

--above/below should achieve that, presuming there's not a different bug
somewhere that prevents this from working correctly.

> And finally: As the internal display is only a 6 bit display, is
> there a way to enable dithering on the 835GM to avoid the banding
> artifacts?

Iirc we always send 8bit data over the dvo bus, so any dithering should be
done in the dvo encoder. The built-in lvds encoder on i855gm and later has
it's own dithering settting, and otherwise I'm not aware of any that would
apply to gen2 graphics.

Also: If you're running sna, have you checked that you indeed run X at
32bit depth? The default since a while is 15 bits.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Sun, Nov 03, 2013 at 06:12:08PM +0100, Daniel Vetter wrote:
> On Sun, Nov 03, 2013 at 05:55:37PM +0100, Thomas Richter wrote:
> > Hi Daniel, dear intel experts,
> > 
> > again trying to get the old Fujitsu laptop to work. The problem with
> > the latest drm-nightly built is that
> > the system again locks up - if the bios is configured to show an
> > image only on the internal display and
> > nothing on the external VGA. If the bios is configured to "shared
> > video", booting works fine.
> > 
> > This seems to be related to the problem that, apparently, the bios
> > seems to prefer to connect the internal
> > display to pipe B and not pipe A, and hence during bootstrap just
> > configuring the dpll for pipe A is not enough.
> > 
> > That being said, the following modifications for ns2501 will fix this:
> > 
> > struct ns2501_priv need to get a new field int pll_b. In
> > enable_dvo(), the setting for the dpll_b needs to be
> > saved, too, and installed, too:
> >     I915_WRITE(_DPLL_A, 0xd0820000);
> >     I915_WRITE(_DPLL_B, 0xd0820000);
> > 
> > It is absolutely unnecessary to overwrite the DVOC register, this is
> > configured fine. In "restore_dvo()", the dpll_b
> > configuration needs to be restored as well. The DVOC register need
> > not to be touched. In fact, the current
> > enable_dvo() has a bug in so far as it saves the wrong register.
> > 
> > However, what is more stunning is how this bug is triggered.
> > Actually, intel_display.c computes the dpll register
> > value correctly (as it seems), but __intel_set_mode() (around line
> > 9356) is a bit strange:
> > 
> > First, it disables the crtcs, then sets the mode, and the enables
> > the crtcs. Unfortunately, this cannot work with
> > with the ns2501 since a disabled PLL will block any communication
> > with with the DVO. I tried to move the "enable"
> > call above the intel_crtc_mode_set(), but this did not work either.
> > I do not know enough about the inner workings
> > of intel_display.c to fix this properly, but the problem seems to be
> > exactly that: An incorrectly configured DPLL
> > disables the communication with the DVO, hence the need for the workaround.
> 
> 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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

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:

------------[ 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.

I will try how the patch performs with an external monitor on.

BTW, there is a second issue related to this laptop: The vertical 
position of the boot console is sometimes off, and sometimes it is not 
visible at all. Sometimes it is too high (the first line is above the 
first line of the monitor) or too
low (the first line is somewhere in the middle of the screen). Seems to 
me that some of the registers should only
be written to at the vertical blank?

Thanks, however! This is so far definitely an improvement. Will report 
back with the two-monitor setup.

Greetings,
     Thomas

Re: More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

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.

Sorry, but using an external monitor is still not working correctly. 
When booting with an external monitor connected, I either get no image 
at all (bios = internal) or flickering on the external monitor and 
nothing internally (bios = shared). When connecting the external monitor 
after X has started, I can get a working image on the monitor, but not 
on the internal panel. The DVO locks up again. If I configure the 
internal panel, then reconfigure the VGA, I get a stable image. If I try 
to change the internal panel dimensions then, I get a flickering 
external screen. The DVO is locked up in either case.

I get the following when switching internally from 800x600 to 1024x768 
(just as an example):

/* snip */

Nov  3 20:12:20 tyleet kernel: [ 1399.497881] [drm:drm_mode_setcrtc], 
[CRTC:4]
Nov  3 20:12:20 tyleet kernel: [ 1399.497890] 
[drm:drm_framebuffer_reference], FB ID: 39
Nov  3 20:12:20 tyleet kernel: [ 1399.497907] [drm:drm_mode_setcrtc], 
[CONNECTOR:8:DVI-I-1]
Nov  3 20:12:20 tyleet kernel: [ 1399.497916] 
[drm:intel_crtc_set_config], [CRTC:4] [FB:39] #connectors=1 (x y) (0 0)
Nov  3 20:12:20 tyleet kernel: [ 1399.497928] 
[drm:intel_set_config_compute_mode_changes], modes are different, full 
mode set
Nov  3 20:12:20 tyleet kernel: [ 1399.497935] 
[drm:drm_mode_debug_printmodeline], Modeline 16:"" 0 40000 800 840 968 
1056 600 601 605 628 0x0 0x5
Nov  3 20:12:20 tyleet kernel: [ 1399.497948] 
[drm:drm_mode_debug_printmodeline], Modeline 16:"" 0 65000 1024 1048 
1184 1344 768 771 777 806 0x0 0xa
Nov  3 20:12:20 tyleet kernel: [ 1399.497960] 
[drm:intel_set_config_compute_mode_changes], computed changes for 
[CRTC:4], mode_changed=1, fb_changed=0
Nov  3 20:12:20 tyleet kernel: [ 1399.497970] 
[drm:intel_modeset_stage_output_state], [CONNECTOR:5:VGA-1] to [CRTC:3]
Nov  3 20:12:20 tyleet kernel: [ 1399.497978] 
[drm:intel_modeset_stage_output_state], [CONNECTOR:8:DVI-I-1] to [CRTC:4]
Nov  3 20:12:20 tyleet kernel: [ 1399.497991] 
[drm:intel_modeset_affected_pipes], set mode pipe masks: modeset: 2, 
prepare: 2, disable: 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498008] 
[drm:connected_sink_compute_bpp], [CONNECTOR:8:DVI-I-1] checking for 
sink bpp constrains
Nov  3 20:12:20 tyleet kernel: [ 1399.498020] 
[drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 24, dithering: 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498028] 
[drm:intel_dump_pipe_config], [CRTC:4][modeset] config for pipe B
Nov  3 20:12:20 tyleet kernel: [ 1399.498036] 
[drm:intel_dump_pipe_config], cpu_transcoder: B
Nov  3 20:12:20 tyleet kernel: [ 1399.498042] 
[drm:intel_dump_pipe_config], pipe bpp: 24, dithering: 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498049] 
[drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 
0, link_m: 0, link_n: 0, tu: 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498058] 
[drm:intel_dump_pipe_config], dp: 0, gmch_m: 0, gmch_n: 0, link_m: 0, 
link_n: 0, tu: 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498066] 
[drm:intel_dump_pipe_config], requested mode:
Nov  3 20:12:20 tyleet kernel: [ 1399.498072] 
[drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 65000 1024 1048 1184 
1344 768 771 777 806 0x0 0xa
Nov  3 20:12:20 tyleet kernel: [ 1399.498084] 
[drm:intel_dump_pipe_config], adjusted mode:
Nov  3 20:12:20 tyleet kernel: [ 1399.498090] 
[drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 65000 1024 1048 1184 
1344 768 771 777 806 0x0 0xa
Nov  3 20:12:20 tyleet kernel: [ 1399.498102] 
[drm:intel_dump_crtc_timings], crtc timings: 65000 1024 1048 1184 1344 
768 771 777 806, type: 0x0 flags: 0xa
Nov  3 20:12:20 tyleet kernel: [ 1399.498112] 
[drm:intel_dump_pipe_config], port clock: 65000
Nov  3 20:12:20 tyleet kernel: [ 1399.498118] 
[drm:intel_dump_pipe_config], pipe src size: 1024x768
Nov  3 20:12:20 tyleet kernel: [ 1399.498125] 
[drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 
0x00000000, lvds border: 0x00000000
Nov  3 20:12:20 tyleet kernel: [ 1399.498132] 
[drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 
0x00000000, disabled
Nov  3 20:12:20 tyleet kernel: [ 1399.498140] 
[drm:intel_dump_pipe_config], ips: 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498145] 
[drm:intel_dump_pipe_config], double wide: 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498158] [drm:ns2501_dpms], 
ns2501_dpms: Trying set the dpms of the DVO to 0
Nov  3 20:12:20 tyleet kernel: [ 1399.498438] [drm:ns2501_writeb], 
Unable to write register 0x08 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.498703] [drm:ns2501_writeb], 
Unable to write register 0x34 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.498968] [drm:ns2501_writeb], 
Unable to write register 0x35 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.498976] [drm:enable_dvo], 
enable_dvo: Trying to re-enable the DVO
Nov  3 20:12:20 tyleet kernel: [ 1399.498985] [drm:enable_dvo], DVOA 
ctrl 0x00000000
Nov  3 20:12:20 tyleet kernel: [ 1399.498991] [drm:enable_dvo], DVOB 
ctrl 0x80004084
Nov  3 20:12:20 tyleet kernel: [ 1399.499006] [drm:enable_dvo], DVOC 
ctrl 0xd000409c
Nov  3 20:12:20 tyleet kernel: [ 1399.499013] [drm:enable_dvo], PLL A 
ctrl 0x90a00000
Nov  3 20:12:20 tyleet kernel: [ 1399.499021] [drm:enable_dvo], PLL B 
ctrl 0xd0840000
Nov  3 20:12:20 tyleet kernel: [ 1399.501050] 
[drm:drm_calc_vbltimestamp_from_scanoutpos], crtc 1 : v 5 p(0,111)@ 
1399.501043 -> 1399.498113 [e 6 us, 0 rep]
Nov  3 20:12:20 tyleet kernel: [ 1399.521076] [drm:i830_get_fifo_size], 
FIFO size - (0x00017e5f) A: 47
Nov  3 20:12:20 tyleet kernel: [ 1399.521103] [drm:intel_calculate_wm], 
FIFO entries required for mode: 99
Nov  3 20:12:20 tyleet kernel: [ 1399.521110] [drm:intel_calculate_wm], 
FIFO watermark level: -54
Nov  3 20:12:20 tyleet kernel: [ 1399.521116] [drm:i830_update_wm], 
Setting FIFO watermarks - A: 1
Nov  3 20:12:20 tyleet kernel: [ 1399.521139] [drm:drm_vblank_get], 
enabling vblank on crtc 1, ret: -22
Nov  3 20:12:20 tyleet kernel: [ 1399.529131] [drm:i8xx_update_pll], 
computed PLL value is 0xd0820000
Nov  3 20:12:20 tyleet kernel: [ 1399.529139] [drm:i8xx_update_pll], 
clock P1 is 4
Nov  3 20:12:20 tyleet kernel: [ 1399.529150] [drm:i8xx_update_pll], 
clock P2 is 4
Nov  3 20:12:20 tyleet kernel: [ 1399.529279] [drm:i9xx_update_plane], 
Writing base 02C00000 00000000 0 0 8192
Nov  3 20:12:20 tyleet kernel: [ 1399.529301] [drm:intel_crtc_mode_set], 
[ENCODER:7:None-7] set [MODE:0:]
Nov  3 20:12:20 tyleet kernel: [ 1399.552060] [drm:ns2501_mode_set], 
ns2501_mode_set: set mode 
(hdisplay=1024,htotal=1344,vdisplay=768,vtotal=806).
Nov  3 20:12:20 tyleet kernel: [ 1399.552081] [drm:ns2501_mode_set], 
ns2501_mode_set: switching to 1024x768
Nov  3 20:12:20 tyleet kernel: [ 1399.552375] [drm:ns2501_writeb], 
Unable to write register 0x37 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.552641] [drm:ns2501_writeb], 
Unable to write register 0x08 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.552650] [drm:enable_dvo], 
enable_dvo: Trying to re-enable the DVO
Nov  3 20:12:20 tyleet kernel: [ 1399.552659] [drm:enable_dvo], DVOA 
ctrl 0x00000000
Nov  3 20:12:20 tyleet kernel: [ 1399.552665] [drm:enable_dvo], DVOB 
ctrl 0x80004084
Nov  3 20:12:20 tyleet kernel: [ 1399.552675] [drm:enable_dvo], DVOC 
ctrl 0xd0004084
Nov  3 20:12:20 tyleet kernel: [ 1399.552682] [drm:enable_dvo], PLL A 
ctrl 0x90a00000
Nov  3 20:12:20 tyleet kernel: [ 1399.552689] [drm:enable_dvo], PLL B 
ctrl 0xd0820000
Nov  3 20:12:20 tyleet kernel: [ 1399.552697] [drm:ns2501_mode_set], 
ns2501_mode_set: switching to 1024x768
Nov  3 20:12:20 tyleet kernel: [ 1399.554019] [drm:ns2501_dpms], 
ns2501_dpms: Trying set the dpms of the DVO to 1
Nov  3 20:12:20 tyleet kernel: [ 1399.554282] [drm:ns2501_writeb], 
Unable to write register 0x08 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.554546] [drm:ns2501_writeb], 
Unable to write register 0x34 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.554810] [drm:ns2501_writeb], 
Unable to write register 0x35 to i915 gmbus dpb:56
Nov  3 20:12:20 tyleet kernel: [ 1399.554817] [drm:enable_dvo], 
enable_dvo: Trying to re-enable the DVO
Nov  3 20:12:20 tyleet kernel: [ 1399.554825] [drm:enable_dvo], DVOA 
ctrl 0x00000000
Nov  3 20:12:20 tyleet kernel: [ 1399.554831] [drm:enable_dvo], DVOB 
ctrl 0x80004084
Nov  3 20:12:20 tyleet kernel: [ 1399.554839] [drm:enable_dvo], DVOC 
ctrl 0xd0004084
Nov  3 20:12:20 tyleet kernel: [ 1399.554846] [drm:enable_dvo], PLL A 
ctrl 0x90a00000
Nov  3 20:12:20 tyleet kernel: [ 1399.554853] [drm:enable_dvo], PLL B 
ctrl 0xd0820000
Nov  3 20:12:20 tyleet kernel: [ 1399.558625] 
[drm:drm_calc_timestamping_constants], crtc 4: hwmode: htotal 1344, 
vtotal 806, vdisplay 768
Nov  3 20:12:20 tyleet kernel: [ 1399.558646] 
[drm:drm_calc_timestamping_constants], crtc 4: clock 65000 kHz framedur 
16665600 linedur 20676, pixeldur 15
Nov  3 20:12:20 tyleet kernel: [ 1399.558673] 
[drm:intel_connector_check_state], [CONNECTOR:5:VGA-1]
Nov  3 20:12:20 tyleet kernel: [ 1399.558943] [drm:ns2501_readb], Unable 
to read register 0x08 from i915 gmbus dpb:0x38.
Nov  3 20:12:20 tyleet kernel: [ 1399.558955] [drm:check_encoder_state], 
[ENCODER:6:DAC-6]
Nov  3 20:12:20 tyleet kernel: [ 1399.558964] [drm:check_encoder_state], 
[ENCODER:7:None-7]
Nov  3 20:12:20 tyleet kernel: [ 1399.558972] [drm:check_crtc_state], 
[CRTC:3]
Nov  3 20:12:20 tyleet kernel: [ 1399.559005] [drm:check_crtc_state], 
[CRTC:4]
Nov  3 20:12:20 tyleet kernel: [ 1399.559027] 
[drm:drm_framebuffer_reference], FB ID: 39
Nov  3 20:12:20 tyleet kernel: [ 1399.559036] 
[drm:drm_framebuffer_unreference], FB ID: 39
Nov  3 20:12:20 tyleet kernel: [ 1399.559042] 
[drm:drm_framebuffer_reference], FB ID: 39
Nov  3 20:12:20 tyleet kernel: [ 1399.559047] 
[drm:drm_framebuffer_unreference], FB ID: 39
Nov  3 20:12:20 tyleet kernel: [ 1399.559059] 
[drm:drm_framebuffer_unreference], FB ID: 39

/* snip */

The drm:enable_dvo lines are from my current version of the patch and 
dump the corresponding i835 registers.

Note the following: Assuming that the internal panel is feed by pipe B 
(I hope I assume right) then the PLL registers
are off. They should be 0xd0820000, but the PLL for pipe B is configured 
to 0xd0840000.

I'll check later what this bit precisely means. One way or another, the 
PLL configuration is not correct to feed the DVO,
and hence I'll get a frozen DVO again. )-:

Greetings,
     Thomas

Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter <thor@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

Re: More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

On 03.11.2013 22:18, Daniel Vetter wrote:
>
> 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 for the patches. Tried quite a bit, and haven't seen the warning 
yet. Looks like the one-monitor
case works quite fine now, except that the boot console is vertically 
"off", which is just annoying though
not problematic.

I also tried a lot with the two-monitor case and again went deeply into 
the DPLL setup logic.
The differences I observed before are simply due to the initial 
resolution (800x600), in the final
resolution, the DPLL settings are actually correct. What I get there is:

--- Configuration found for regular display 1024x768:

Nov  3 23:33:30 tyleet kernel: [    9.122481] [drm:i9xx_find_best_dpll], 
clock.m1 = 21
Nov  3 23:33:30 tyleet kernel: [    9.122483] [drm:i9xx_find_best_dpll], 
clock.m2 = 13
Nov  3 23:33:30 tyleet kernel: [    9.122485] [drm:i9xx_find_best_dpll], 
clock.n  = 4
Nov  3 23:33:30 tyleet kernel: [    9.122488] [drm:i9xx_find_best_dpll], 
clock.p1 = 4

for 800x600:

Nov  3 23:38:41 tyleet kernel: [  368.725507] [drm:i9xx_find_best_dpll], 
clock.m1 = 19
Nov  3 23:38:41 tyleet kernel: [  368.725514] [drm:i9xx_find_best_dpll], 
clock.m2 = 13
Nov  3 23:38:41 tyleet kernel: [  368.725521] [drm:i9xx_find_best_dpll], 
clock.n  = 4
Nov  3 23:38:41 tyleet kernel: [  368.725528] [drm:i9xx_find_best_dpll], 
clock.p1 = 6

640 x 480:

Nov  3 23:40:05 tyleet kernel: [  452.965855] [drm:i9xx_find_best_dpll], 
clock.m1 = 20
Nov  3 23:40:05 tyleet kernel: [  452.965862] [drm:i9xx_find_best_dpll], 
clock.m2 = 14
Nov  3 23:40:05 tyleet kernel: [  452.965869] [drm:i9xx_find_best_dpll], 
clock.n  = 3
Nov  3 23:40:05 tyleet kernel: [  452.965876] [drm:i9xx_find_best_dpll], 
clock.p1 = 12

And even in the two-monitor case, the DPLL for DPLL_B is setup 
correctly. Thus, *that* does not seem the
cause of the problem.

What is different is the DVO setting:
bit differences:

In the two-monitor case, the internal DVOC register is 0xd000409c, in 
the one-monitor case it is: 0x90004084

Differences are:

DVO bit 30 should be 0 is 1.  DVO_PIPE_B_SELECT    enabled
DVO bit 4 should be 0 is 1.   DVO_VSYNC_ACTIVE_HIGH
DVO bit 3 should be 0 is 1.   DVO_HSYNC_ACTIVE_HIGH

Now, the bit 30 is clear, though I wonder why the sync signal is inverted.

Anyhow, something else makes we wonder. The DVO-reactivation code *does* 
work (the DVO-settings do not block,
though the DVO blocks afterwards), and the code is just:

     I915_WRITE(_DPLL_A, 0xd0820000);
     I915_WRITE(_DPLL_B, 0xd0820000);

Thus, while the DPLL_B register is just overwritten by the same value, 
though DPLL_A changes. The fact that this actually
unlocks the DVO means to me that actually bit 30 of the DVOC register 
*does not* work to re-assign the DVO to pipe B.
The way how the system behaves is rather consistent with the hypothesis 
that the DVO is still assigned to pipe A????

Is there any other bit or setting that controls which DVO goes to which 
pipe? It looks like the pipe output control does
not work correctly.

Greetings,
     Thomas

16bpp and 8bpp uxa output broken...

[Thomas Richter]

Hi Daniel, dear intel experts,

just another note: I just switched the default depth from 24 to 16 bit 
by adding a "DefaultDepth" into
the screen section of X11. Strangely enough, that gives much *less* 
banding than the 24bpp output????

Anyhow, 16bpp breaks the gdm login, and 8bpp breaks almost everything. 
Strangely, if I switch from uxa
to sna, gdm is fine and the graphics is much smoother (less banding) 
than with 24bpp output.

Greetings,
     Thomas

P.S.: Strangely enough, with the 24bpp output, I can clearly count 64 
distinct grey levels corresponding to
the 6bpp panel (I assume), with 16bpp output, I get a somewhat more 
irregular banding (probably because
green has one bit more), though the desktop background is very smooth. 
The same image, when viewed
by eog, shows banding. Thus, I suppose, that the desktop renderer 
applies some kind of dithering while
eog does not. Wierd.

Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Mon, Nov 4, 2013 at 12:09 AM, Thomas Richter <thor@math.tu-berlin.de> wrote:
> On 03.11.2013 22:18, Daniel Vetter wrote:
>>
>>
>> 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 for the patches. Tried quite a bit, and haven't seen the warning yet.
> Looks like the one-monitor
> case works quite fine now, except that the boot console is vertically "off",
> which is just annoying though
> not problematic.

Awesome. I'll try to merge these patches with cc: stable.

> I also tried a lot with the two-monitor case and again went deeply into the
> DPLL setup logic.
> The differences I observed before are simply due to the initial resolution
> (800x600), in the final
> resolution, the DPLL settings are actually correct. What I get there is:

I suspect that due to the pipe A quirk logic we actually get the setup
sequence for the DPLLs completely wrong. This will require a bit more
magic to make it work correctly ... But I have some ideas.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: 16bpp and 8bpp uxa output broken...

[Daniel Vetter]

On Mon, Nov 4, 2013 at 12:56 AM, Thomas Richter <thor@math.tu-berlin.de> wrote:
>
> just another note: I just switched the default depth from 24 to 16 bit by
> adding a "DefaultDepth" into
> the screen section of X11. Strangely enough, that gives much *less* banding
> than the 24bpp output????

That just means we dither down in sw/hw to 16 bit, instead of
rendering at 24 and then doing no dithering at all.

> Anyhow, 16bpp breaks the gdm login, and 8bpp breaks almost everything.
> Strangely, if I switch from uxa
> to sna, gdm is fine and the graphics is much smoother (less banding) than
> with 24bpp output.

Iirc SNA enables all the neat hw dithering options. It also works
correctly at 16 bit, although you'll run into trouble with qt/kde
stuff and with opengl apps.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

Hi Daniel,
>> I also tried a lot with the two-monitor case and again went deeply into the
>> DPLL setup logic.
>> The differences I observed before are simply due to the initial resolution
>> (800x600), in the final
>> resolution, the DPLL settings are actually correct. What I get there is:
> I suspect that due to the pipe A quirk logic we actually get the setup
> sequence for the DPLLs completely wrong. This will require a bit more
> magic to make it work correctly ... But I have some ideas.
> -Daniel
Well,  maybe. The register contents that are listed in my mail are read 
out from the hardware exactly when the
DVO gets stuck, actually right before it. From what I can see from there 
is that the PLL setup and DVO setup
look actually ok (from what I can tell). What is also remarkable is that 
the DVO-reenable logic does succeed by
writing the same value to the DPLL_A and DPLL_B registers, which is the 
proper value for a 1024x768 screen. However,
the DPLL_B register value is correct, whereas the DPLL_A register 
contains values that are likely useful for the VGA
output.

Now, here is the miracle: The DVOC register indicates that the DVO gets 
its input from pipe B. However, writing the
correct value into DPLL_A (!) (remember, DPLL_B is already set 
correctly) revives the DVO.

Thus, I wonder how this can be. The only explanation I have is that the 
DVO is still fed by pipe A, and not by pipe B.
Maybe there is something else that needs to be done to switch the DVO to 
pipe B.

Anyhow, happy to take your ideas. Unfortunately, I will again not have 
this specific laptop available for some while. I do have an R31 for 
testing, though its display is connected via LVDS and not via a DVO. The 
chipset seems to be similar otherwise, though.

Greetings,
     Thomas

Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote:
> Hi Daniel,
> >>I also tried a lot with the two-monitor case and again went deeply into the
> >>DPLL setup logic.
> >>The differences I observed before are simply due to the initial resolution
> >>(800x600), in the final
> >>resolution, the DPLL settings are actually correct. What I get there is:
> >I suspect that due to the pipe A quirk logic we actually get the setup
> >sequence for the DPLLs completely wrong. This will require a bit more
> >magic to make it work correctly ... But I have some ideas.
> >-Daniel
> Well,  maybe. The register contents that are listed in my mail are
> read out from the hardware exactly when the
> DVO gets stuck, actually right before it. From what I can see from
> there is that the PLL setup and DVO setup
> look actually ok (from what I can tell). What is also remarkable is
> that the DVO-reenable logic does succeed by
> writing the same value to the DPLL_A and DPLL_B registers, which is
> the proper value for a 1024x768 screen. However,
> the DPLL_B register value is correct, whereas the DPLL_A register
> contains values that are likely useful for the VGA
> output.
> 
> Now, here is the miracle: The DVOC register indicates that the DVO
> gets its input from pipe B. However, writing the
> correct value into DPLL_A (!) (remember, DPLL_B is already set
> correctly) revives the DVO.
> 
> Thus, I wonder how this can be. The only explanation I have is that
> the DVO is still fed by pipe A, and not by pipe B.
> Maybe there is something else that needs to be done to switch the
> DVO to pipe B.

That's actually my suspicion. Most of these registers here are
double-buffered and only take effect if preconditions are right. Due to
our pipe A quirk we never shut down pipe A, so the pll updates might not
actually take effect at all (but the registers have the new values
already). There's unfortunately no registers to get at the actual hw
state, and only later hw generations have added at least a few bits to
indicate whether the large transitions (on/off) have actually happened.

The problem is that I don't yet have a clear idea how to do the pipe A
quirk correctly :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: More questions and patches for 835GM/ns2501 DVO

[Ville Syrjälä]

On Mon, Nov 04, 2013 at 04:15:09PM +0100, Daniel Vetter wrote:
> On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote:
> > Hi Daniel,
> > >>I also tried a lot with the two-monitor case and again went deeply into the
> > >>DPLL setup logic.
> > >>The differences I observed before are simply due to the initial resolution
> > >>(800x600), in the final
> > >>resolution, the DPLL settings are actually correct. What I get there is:
> > >I suspect that due to the pipe A quirk logic we actually get the setup
> > >sequence for the DPLLs completely wrong. This will require a bit more
> > >magic to make it work correctly ... But I have some ideas.
> > >-Daniel
> > Well,  maybe. The register contents that are listed in my mail are
> > read out from the hardware exactly when the
> > DVO gets stuck, actually right before it. From what I can see from
> > there is that the PLL setup and DVO setup
> > look actually ok (from what I can tell). What is also remarkable is
> > that the DVO-reenable logic does succeed by
> > writing the same value to the DPLL_A and DPLL_B registers, which is
> > the proper value for a 1024x768 screen. However,
> > the DPLL_B register value is correct, whereas the DPLL_A register
> > contains values that are likely useful for the VGA
> > output.
> > 
> > Now, here is the miracle: The DVOC register indicates that the DVO
> > gets its input from pipe B. However, writing the
> > correct value into DPLL_A (!) (remember, DPLL_B is already set
> > correctly) revives the DVO.
> > 
> > Thus, I wonder how this can be. The only explanation I have is that
> > the DVO is still fed by pipe A, and not by pipe B.
> > Maybe there is something else that needs to be done to switch the
> > DVO to pipe B.
> 
> That's actually my suspicion. Most of these registers here are
> double-buffered and only take effect if preconditions are right. Due to
> our pipe A quirk we never shut down pipe A, so the pll updates might not
> actually take effect at all (but the registers have the new values
> already). There's unfortunately no registers to get at the actual hw
> state, and only later hw generations have added at least a few bits to
> indicate whether the large transitions (on/off) have actually happened.
> 
> The problem is that I don't yet have a clear idea how to do the pipe A
> quirk correctly :(

Could it be that we should only have the 2x DVO clock enable bit set
in the correct DPLL register?

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 8f40ae3..4b02890 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1470,8 +1470,11 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
 static void i9xx_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
        /* Don't disable pipe A or pipe A PLLs if needed */
-       if (pipe == PIPE_A && (dev_priv->quirks & QUIRK_PIPEA_FORCE))
+       if (pipe == PIPE_A && (dev_priv->quirks & QUIRK_PIPEA_FORCE)) {
+               /* disable 2x DVO clock output */
+               I915_WRITE(DPLL(pipe), I915_READ(DPLL(pipe) & ~DPLL_2X_MODE));
                return;
+       }
 
        /* Make sure the pipe isn't still relying on us */
        assert_pipe_disabled(dev_priv, pipe);


> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

Re: More questions and patches for 835GM/ns2501 DVO

[Ville Syrjälä]

On Mon, Nov 04, 2013 at 05:48:16PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 04, 2013 at 04:15:09PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote:
> > > Hi Daniel,
> > > >>I also tried a lot with the two-monitor case and again went deeply into the
> > > >>DPLL setup logic.
> > > >>The differences I observed before are simply due to the initial resolution
> > > >>(800x600), in the final
> > > >>resolution, the DPLL settings are actually correct. What I get there is:
> > > >I suspect that due to the pipe A quirk logic we actually get the setup
> > > >sequence for the DPLLs completely wrong. This will require a bit more
> > > >magic to make it work correctly ... But I have some ideas.
> > > >-Daniel
> > > Well,  maybe. The register contents that are listed in my mail are
> > > read out from the hardware exactly when the
> > > DVO gets stuck, actually right before it. From what I can see from
> > > there is that the PLL setup and DVO setup
> > > look actually ok (from what I can tell). What is also remarkable is
> > > that the DVO-reenable logic does succeed by
> > > writing the same value to the DPLL_A and DPLL_B registers, which is
> > > the proper value for a 1024x768 screen. However,
> > > the DPLL_B register value is correct, whereas the DPLL_A register
> > > contains values that are likely useful for the VGA
> > > output.
> > > 
> > > Now, here is the miracle: The DVOC register indicates that the DVO
> > > gets its input from pipe B. However, writing the
> > > correct value into DPLL_A (!) (remember, DPLL_B is already set
> > > correctly) revives the DVO.
> > > 
> > > Thus, I wonder how this can be. The only explanation I have is that
> > > the DVO is still fed by pipe A, and not by pipe B.
> > > Maybe there is something else that needs to be done to switch the
> > > DVO to pipe B.
> > 
> > That's actually my suspicion. Most of these registers here are
> > double-buffered and only take effect if preconditions are right. Due to
> > our pipe A quirk we never shut down pipe A, so the pll updates might not
> > actually take effect at all (but the registers have the new values
> > already). There's unfortunately no registers to get at the actual hw
> > state, and only later hw generations have added at least a few bits to
> > indicate whether the large transitions (on/off) have actually happened.
> > 
> > The problem is that I don't yet have a clear idea how to do the pipe A
> > quirk correctly :(
> 
> Could it be that we should only have the 2x DVO clock enable bit set
> in the correct DPLL register?
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 8f40ae3..4b02890 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1470,8 +1470,11 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
>  static void i9xx_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
>  {
>         /* Don't disable pipe A or pipe A PLLs if needed */
> -       if (pipe == PIPE_A && (dev_priv->quirks & QUIRK_PIPEA_FORCE))
> +       if (pipe == PIPE_A && (dev_priv->quirks & QUIRK_PIPEA_FORCE)) {
> +               /* disable 2x DVO clock output */
> +               I915_WRITE(DPLL(pipe), I915_READ(DPLL(pipe) & ~DPLL_2X_MODE));

And that should be ~DPLL_DVO_2X_MODE obviously.

>                 return;
> +       }
>  
>         /* Make sure the pipe isn't still relying on us */
>         assert_pipe_disabled(dev_priv, pipe);
> 
> 
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

Patches for i830 flicker on panning

[Thomas Richter]

Hi Daniel, dear intel experts,

the following is a "solution" for the flicker on i830 panning. To remind 
you, when panning is enabled on an i830,
the display shows an annoying 30Hz flicker on some "forbidden" 
positions. On such positions, half of the frames
is black, and the other half shows a screen that is "ripped in half", 
with one half scrolled to the wrong
position, and the other half displayed correctly, with a discontinuity 
in the middle.
That is, every other frame is black, and the ones that are not black are 
"wrong".

The patch is, arguably, ugly as hell, and creates a certain "yerkiness", 
though it does its job. One of the side
effects this flicker causes is complete crashes and lockups with video 
overlays which are avoided by the patch.
That is, if you play a video with xine, and then pan over a forbidden 
position, the machine crashes and comes
to a complete stop.

Sorry if the patch format isn't quite right, and the patch is not quite 
in a final state (not yet fully tested on all possible
combinations of panning dimensions and display depths), but it's a start 
and "works good enough for me".

For that, patch: i9xx_update_plane(...) in intel_display.c,

     if (INTEL_INFO(dev)->gen >= 4) {
         I915_MODIFY_DISPBASE(DSPSURF(plane),
                      i915_gem_obj_ggtt_offset(obj) + 
intel_crtc->dspaddr_offset);
         I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
         I915_WRITE(DSPLINOFF(plane), linear_offset);
+    } else if (INTEL_INFO(dev)->gen == 2) {
+      int xflick = (x >> 4) & 0x03;
+      if (xflick == 3) {       /* in forbidden column, probably a i830 
bug */
+        int xfix  = 16 + (x & ~(0x3f));
+        int fix_offset = y * fb->pitches[0] + xfix * 
(fb->bits_per_pixel / 8);
+        I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) + 
fix_offset);
+        POSTING_READ(reg);
+        intel_wait_for_vblank(dev, intel_crtc->pipe);
+      }
+      I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) + 
linear_offset);
     } else
         I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) + 
linear_offset);
     POSTING_READ(reg);

The trick is, as you see, first to display the one frame the display 
scrolled off *before* the forbidden column, and
then scroll to the right position, going to the right. )-:

*Why* that works is unclear to me. Don't ask, just observation.

An improvement would be to check whether the x position did change, and 
if it did not, just avoid all the hack to
allow smooth vertical scrolling. Still to be done. Maybe later the week 
if the above also works on the R31
(affected by the same problem).

Greetings,
     Thomas

Re: Patches for i830 flicker on panning

[Daniel Vetter]

On Tue, Nov 05, 2013 at 12:20:58AM +0100, Thomas Richter wrote:
> Hi Daniel, dear intel experts,
> 
> the following is a "solution" for the flicker on i830 panning. To
> remind you, when panning is enabled on an i830,
> the display shows an annoying 30Hz flicker on some "forbidden"
> positions. On such positions, half of the frames
> is black, and the other half shows a screen that is "ripped in
> half", with one half scrolled to the wrong
> position, and the other half displayed correctly, with a
> discontinuity in the middle.
> That is, every other frame is black, and the ones that are not black
> are "wrong".
> 
> The patch is, arguably, ugly as hell, and creates a certain
> "yerkiness", though it does its job. One of the side
> effects this flicker causes is complete crashes and lockups with
> video overlays which are avoided by the patch.
> That is, if you play a video with xine, and then pan over a
> forbidden position, the machine crashes and comes
> to a complete stop.
> 
> Sorry if the patch format isn't quite right, and the patch is not
> quite in a final state (not yet fully tested on all possible
> combinations of panning dimensions and display depths), but it's a
> start and "works good enough for me".

Patch is pretty badly whitespace mangled please format it according to
Documentation/SubmittingPatches (git format-patch preferred). Also I think
we should conditionalize this on i830M only, I don't see any other
reports.

One thing to try out still: Does this still work if you tell the ddx to
use a linear frontbuffer?
-Daniel


> 
> For that, patch: i9xx_update_plane(...) in intel_display.c,
> 
>     if (INTEL_INFO(dev)->gen >= 4) {
>         I915_MODIFY_DISPBASE(DSPSURF(plane),
>                      i915_gem_obj_ggtt_offset(obj) +
> intel_crtc->dspaddr_offset);
>         I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
>         I915_WRITE(DSPLINOFF(plane), linear_offset);
> +    } else if (INTEL_INFO(dev)->gen == 2) {
> +      int xflick = (x >> 4) & 0x03;
> +      if (xflick == 3) {       /* in forbidden column, probably a
> i830 bug */
> +        int xfix  = 16 + (x & ~(0x3f));
> +        int fix_offset = y * fb->pitches[0] + xfix *
> (fb->bits_per_pixel / 8);
> +        I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) +
> fix_offset);
> +        POSTING_READ(reg);
> +        intel_wait_for_vblank(dev, intel_crtc->pipe);
> +      }
> +      I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) +
> linear_offset);
>     } else
>         I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) +
> linear_offset);
>     POSTING_READ(reg);
> 
> The trick is, as you see, first to display the one frame the display
> scrolled off *before* the forbidden column, and
> then scroll to the right position, going to the right. )-:
> 
> *Why* that works is unclear to me. Don't ask, just observation.
> 
> An improvement would be to check whether the x position did change,
> and if it did not, just avoid all the hack to
> allow smooth vertical scrolling. Still to be done. Maybe later the
> week if the above also works on the R31
> (affected by the same problem).
> 
> Greetings,
>     Thomas
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Sun, Nov 03, 2013 at 10:18:14PM +0100, Daniel Vetter wrote:
> 
> On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter <thor@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));
>  }

To clarify: Do you need this patch to make the single-pipe mode work
reliably? It's a bit unclear in your answer ...

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

On 06.11.2013 11:34, Daniel Vetter wrote:
>>   }
>
> To clarify: Do you need this patch to make the single-pipe mode work
> reliably? It's a bit unclear in your answer ...

Well, from what I can tell, I haven't seen the above warning since, but 
it was neither easily reproducable. "Working reliable" is probably a bit 
too much. (-; No, the vertical position of the boot console is off, 
panning flickers, and the two-monitor case is close to non-working. But 
other than that, it works now regardless of whether the bios is set to 
internal or shared monitors.

So I would guess it works as good as it currently can. (-:

The harddisk of the R31 (the other laptop with the same dreadful 
chipset) died today, so I fished a "new old one" from our pile of junk, 
and re-installed Linux. It currently compiles the latest git, so please 
have some patience with a 1.2Ghz Celeron. Will be ready tomorrow, 
hopefully with more results for the "anti-flicker" patch.

Anyhow. This patch is currently *only* tested for the linear framebuffer 
alignment, and most certainly not "right". I believe its some sort of 
memory alignment issue, and I need to dig a bit deeper what exactly 
happens there.

Greetings,
	Thomas

Re: More questions and patches for 835GM/ns2501 DVO

[Daniel Vetter]

On Wed, Nov 06, 2013 at 11:34:05AM +0100, Daniel Vetter wrote:
> On Sun, Nov 03, 2013 at 10:18:14PM +0100, Daniel Vetter wrote:
> > 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));
> >  }
> 
> To clarify: Do you need this patch to make the single-pipe mode work
> reliably? It's a bit unclear in your answer ...

To clarify my clarification question: Do you need the above quoted patch
to make the cursor work better on your system? This is not about a WARN or
the flicker or dual pipe (last time I've asked you kinda went on a
tangent). I'm asking again since this patch for the cursor code is
currently blocked from merging because I couldn't get a clear "this is
needed, yes" from you.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

On 15.11.2013 18:33, Daniel Vetter wrote:

>> To clarify: Do you need this patch to make the single-pipe mode work
>> reliably? It's a bit unclear in your answer ...
>
> To clarify my clarification question: Do you need the above quoted patch
> to make the cursor work better on your system?

Well, at least it avoided one kernel warning. Or rather, I haven't seen 
it since. But otherwise, the cursor works fine. I don't have any 
problems with the cursor whatsoever, it always appears.

> This is not about a WARN or
> the flicker or dual pipe (last time I've asked you kinda went on a
> tangent). I'm asking again since this patch for the cursor code is
> currently blocked from merging because I couldn't get a clear "this is
> needed, yes" from you.

It's hard to say whether it is needed, unfortunately. The kernel warning 
is not so easy to provoke, and there is no clear way to reproduce it. 
All I can say is that I haven't seen it since, and the patch has surely 
not made anything worse, so I would say go for it and include it.

Greetings,
	Thomas