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