This is the complete set of patches that yield a working 3-pipe mode
setting configuration on my test machines. It does not make DPMS work,
so I still need to figure that out. As the DPMS paths are almost
entirely different from mode setting (whose crazy idea was that,
anyway?), that may take a bit more time.
I've managed to reproduce this bug with only two monitors just by
forcing them onto FDI B/C, but only with 1920x1080 and larger modes:
$ xrandr --output VGA1 --off --output DP1 --off
$ xrandr --output VGA1 --auto --crtc 1
$ xrandr --output DP1 --auto --crtc 2
That works about 50% of the time on the original kernel. If it works,
you can just try a couple of different modes to see if you can get it
to fail. Just use reasonably large modes -- 640x480 has never failed
for me. I'd love to know why
$ xrandr --output DP1 --mode 1600x1200 --crtc 2
Finally, the X server has a terrible bug in the RandR code. It
computes a desired initial configuration, and if that fails in any
way, it refuses to start at all. So, if you connect three monitors
that all require separate PLLs, then you get two monitors lit up, the
third one fails and the X server aborts. Need to fix that so that if
*any* monitors light up, the X server will keep going.
*** The patches: ***
[PATCH 1/7] drm/i915: Allow VGA on CRTC 2
Silly hold-over from the bad-old PLL sharing code.
[PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge
Here's the patch which rejects modes that the FDI B/C lane sharing
hardware can't support. This only affects modes larger than 1920x1200
though as that mode and smaller all fit in two FDI lanes. I ran across
this while testing with a 2560x1200 monitor.
[PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear
This seems like a sensible change in the FDI link training code --
gives the FDI hardware time to adapt to changes in the
signalling. But, as I've never seen FDI fail to train, I'm not sure
it's useful.
[PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after
This mostly just cleans up some debug messages by moving various BPP
computations around. "should" have no effect on the hardware.
[PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR
Just happened across this obvious bug while reading through the
driver.
[PATCH 6/7] drm/i915: Disable FDI RX before FDI TX
The specs don't say which order to do this in, but it doesn't make
sense to do these in the current order. With this in place, I saw mode
setting errors reduced quite a bit, but not gone.
[PATCH 7/7] drm/i915: Merge FDI RX reg writes during training
This may be the only patch necessary to get mode setting working on
FDI-B/C, it ensures that error correction is always turned on during
link training. The old code left error correction disabled as there
was no posting read after setting that. I'm hoping this explains why
the problem wasn't reliably reproducible -- the problem depended on
how long the write waited to get to the hardware. I haven't done
enough testing of this patch in isolation to know if this is true or not.
-keith
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
