drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo

drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo

Our handling of the crtc timing computation has been nicely
cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over
the place. But with

commit c86c3b7e7d7a5ffe9065ee246c9903dd98704060
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Apr 15 19:53:19 2012 +0200

    drm/i915: don't clobber the special upscaling lvds timings

and

commit 1adade9bdfc8bfe2579034a5cfa2450fc96e78d5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jan 28 14:49:20 2012 +0100

    drm/i915: fixup interlaced vertical timings confusion, part 1

we now only set the crtc timing fields in the encoder->mode_fixup
(lvds only) and in crtc->mode_fixup (for everyone else). And since

commit 39ebf510f4ed76fcd8995a4faae1e66e5ef72447
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jan 28 23:48:46 2012 +0100

    drm/i915: fixup overlay checks for interlaced modes

the only places we actually need the crtc timings is in the mode_set
function.

I guess the idea of the drm core is that every time it creates a drm
mode, it also sets the timings. But afaics it never uses them, safe
for the precise vblank timestamp code (but that can only run on active
modes, i.e.  after our mode_fixup functions have been called). The
problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the
timings are pretty much bogus for us anyway (at least with interlaced
support).

So I guess it's the drivers job that every active modes needs to have
crtc timings that suits it, and with these patches we should have
that. drm core doesn't seem to care about modes that just get passed
around. Hence we can now safely rip out all the remaining calls to
set_crtcinfo left in the driver and clean up this confusion.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>