Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the new drm/i915 code depends upon to be
absolutely correct.

The crtc helper itself doesn't really care about that, since it
disables unused encoders in a rather roundabout way anyway.

Two places call drm_setup_crts:

- For the initial fb config. I've auditted all current drivers, and
  they all allocate their encoders with kzalloc. So there's no need to
  clear encoder->crtc once more.

- When processing hotplug events while showing the fb console. This
  one is a bit more tricky, but both the crtc helper code and the new
  drm/i915 modeset code disable encoders if their crtc is changed and
  that encoder isn't part of the new config. Also, both disable any
  disconnected outputs, too.

  Which only leaves encoders that are on, connected, but for some odd
  reason the fb helper code doesn't want to use. That would be a bug
  in the fb configuration selector, since it tries to light up as many
  outputs as possible.

v2: Kill the now unused encoders variable.
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>