]> git.openfabrics.org - ~shefty/rdma-dev.git/commit
drm/fb-helper: don't clobber output routing in setup_crtcs
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Sun, 12 Aug 2012 16:15:48 +0000 (18:15 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Fri, 17 Aug 2012 08:10:05 +0000 (10:10 +0200)
commit33faad195eec0c72fec84e638623ea25652eed72
treee0c21b82086793eef257bf3ab4fb2b16c73d7c97
parent9b138a83675364366388af8b6986b2e52be36bcc
drm/fb-helper: don't clobber output routing in setup_crtcs

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>
drivers/gpu/drm/drm_fb_helper.c