So apparently under ridiculous amounts of memory pressure we can get
into trouble in do_switch when we try to move the old hw context
backing storage object onto the active lists.

With list debugging enabled that usually results in us chasing a
poisoned pointer - which means we've hit upon a vma that has been
removed from all lrus with list_del (and then deallocated, so it's a
real use-after free).

Ian Lister has done some great callchain chasing and noticed that we
can reenter do_switch:

i915_gem_do_execbuffer()

i915_switch_context()

do_switch()
   from = ring->last_context;
   i915_gem_object_pin()

      i915_gem_object_bind_to_gtt()
         ret = drm_mm_insert_node_in_range_generic();
         // If the above call fails then it will try i915_gem_evict_something()
         // If that fails it will call i915_gem_evict_everything() ...
	 i915_gem_evict_everything()
	    i915_gpu_idle()
	       i915_switch_context(DEFAULT_CONTEXT)

Like with everything else where the shrinker or eviction code can
invalidate pointers we need to reload relevant state.

Note that there's no need to recheck whether a context switch is still
required because:

- Doing a switch to the same context is harmless (besides wasting a
  bit of energy).

- This can only happen with the default context. But since that one's
  pinned we'll never call down into evict_everything under normal
  circumstances. Note that there's a little driver bringup fun
  involved namely that we could recourse into do_switch for the
  initial switch. Atm we're fine since we assign the context pointer
  only after the call to do_switch at driver load or resume time. And
  in the gpu reset case we skip the entire setup sequence (which might
  be a bug on its own, but definitely not this one here).

Cc'ing stable since apparently ChromeOS guys are seeing this in the
wild (and not just on artificial stress tests), see the reference.

Note that in upstream code doesn't calle evict_everything directly
from evict_something, that's an extension in this product branch. But
we can still hit upon this bug (and apparently we do, see the linked
backtraces). I've noticed this while trying to construct a testcase
for this bug and utterly failed to provoke it. It looks like we need
to driver the system squarly into the lowmem wall and provoke the
shrinker to evict the context object by doing the last-ditch
evict_everything call.

Aside: There's currently no means to get a badly-fragmenting hw
context object away from a bad spot in the upstream code. We should
fix this by at least adding some code to evict_something to handle hw
contexts.

References: https://code.google.com/p/chromium/issues/detail?id=248191Reported-by: NIan Lister <ian.lister@intel.com>
Cc: Ian Lister <ian.lister@intel.com>
Cc: stable@vger.kernel.org
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Bloomfield, Jon <jon.bloomfield@intel.com>
Tested-by: NRafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: NIan Lister <ian.lister@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Shovel a bit more of the the code into the setup function, and call
it earlier. Otherwise lockdep is unhappy since we cancel the delayed
resume work before it's initialized.

While at it also shovel the pc8 setup code into the same functions.
I wanted to also ditch the header declaration of the hws pc8 functions,
but for unfathomable reasons that stuff is in intel_display.c instead
of intel_pm.c.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71980Tested-by: NGuo Jinxian <jinxianx.guo@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Inorder to serialise the closing of the file descriptor and its
subsequent release of client requests with i915_gem_free_request(), we
need to hold the struct_mutex in i915_gem_release(). Failing to do so
has the potential to trigger an OOPS, later with a use-after-free.

Testcase: igt/gem_close_race
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70874
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71029Reported-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't have clock state readout support for DDI, so skip the pipe
config clock checks on all DDI platforms.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial connector statuses and prepares the
hardware for a thorough probing. However, during a lid event, we only
want to undo the damage caused by the bios by resetting our last known
mode. In this cirumstance, we do not want to clobber our desired state.

In order to try and keep sanity between the config state and our own
tracking, do the drm_mode_config_reset() first along the load/resume
paths before reading out the hw state and apply any definite known
corrections.

v2: "As discussed on irc I don't think we should force the connector
state to anything here: Imo connector->status should reflect what we
believe to be the true output connection state, whereas connector->encoder
reflects whether this connector is wired up to a pipe. And since we no
longer reject modeset on disconnected connectors and never nuked the pipe
if the connector gets disconnected there's no reason for that - such policy
is userspace's job.

This regression has been introduced in

commit 2e938892
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 11 20:08:24 2012 +0200

    drm/i915/crt: explicitly set up HOTPLUG_BITS on resume"
so sayeth Daniel.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org (v3.8 and later)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.

Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Tested-and-reported-by: NPaul Bolle <pebolle@tiscali.nl>
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During the vmap() routine for the dma-buf, we first grab the pages and
then try to allocate a temporary array to pass to the vmap(). However,
the shrinker can and will reap any object that is unbound if the
allocation for the array first fails. This includes the object which we
are attempting to vmap(). The solution is to mark the object's pages as
pinned whilst we try the allocation to prevent the use-after-free
introduced by the potential shrinkage.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The MI_PREDICATE_RESULT_2 register exits only on HSW. On other
platforms the same offset is either reserved, or contains some
other register. So write the register only on HSW.

This regression has been introduced in

commit 9435373e
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Wed Aug 28 16:45:46 2013 -0300

    drm/i915: Report enabled slices on Haswell GT3
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add regression notice.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The ring scratch pages don't have a PPGTT mapping, so the DERRM SRM
should target the global GTT instead.

v2: Add MI_SRM_LRM_GLOBAL_GTT define for -fixes
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
a second version of the patch to correct this problem. The problem is
that v1 was merged instead of v2.

I was able to notice the problem when running the
debugfs-forcewake-user subtest of pm_pc8 from intel-gpu-tools.

Cc: stable@vger.kernel.org
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We were miscalculating the pipe CSC post offset for the full->limited
range conversion. The resulting post offset was double what it was
supposed to be, which caused blacks to come out grey when using
limited range output on HSW+.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769
Cc: stable@vger.kernel.org
Tested-by: NLauri Mylläri <lauri.myllari@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reduce the eDP detection to just checking if it's port A, or if
the VBT tells us that the port is eDP for the other ports.
Suggested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV can have eDP on either port B or C, or even both. Based on the
VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we
check the correct ports.

So instead of hardcoding port D, rename the function to
intel_dp_is_edp() and pass the port as a parameter, and use it
on VLV ports B and C.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051Tested-by: NRobert Hooker <robert.hooker@canonical.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Wrestle the patch to apply and compile properly.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This value is more correct, and matches what we read out in the fastboot
code.  Without this, the watermark code will panic after the first mode
setting activity after a fastboot.

v2: fix up HSW ->clock usage too (Ville)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As the execbuffer dispatch grows ever more complex and involves multiple
stages of moving objects into the aperture, we need to take greater care
that we do not evict our execbuffer objects prior to dispatch. This is
relatively simple as we can just keep the objects pinned for not just
the relocation but until we are finished.

One such example is the possibility of the context switch causing an
eviction or hitting the shrinker in order to fit its object into the
aperture.

Link: http://lists.freedesktop.org/archives/intel-gfx/2013-November/036166.htmlReported-by: N"Siluvery, Arun" <arun.siluvery@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Tested-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Add the additional explanations from Chris to the commit
message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is just a theoretical issue, but we need to do this to prevent the
WARN in pipe_from_connector at suspend time.

This regression has been introduce in

commit 7bd688cd
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Nov 8 16:48:56 2013 +0200

    drm/i915: handle backlight through chip specific functions

https://bugs.freedesktop.org/show_bug.cgi?id=71978Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have conflicting benchmark data that suggest either age 0 or age 3 is
better. However, the earlier benchmark on which we based the switch to
age 0

(commit 0d8ff15e
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Thu Jul 4 11:02:03 2013 -0700

    drm/i915/hsw: Set correct Haswell PTE encodings)

actually seems to prefer the default PTE encoding as age 3. Presumably,
this is in part due to the use of MOCS to override the PTE encodings
when appropriate.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69870
Tested-by: mengmeng.meng@intel.com
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eric Anholt <eric@anholt.net
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Similar to
commit fdbc3b1f
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Nov 12 17:10:13 2013 +0200

    drm/i915/dp: set sink to power down mode on dp disable

but for DDI, where we've never done this.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This regression has been introduced in

commit 4fe8590a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Sep 4 18:25:22 2013 +0300

    drm/i915: Use adjusted_mode appropriately when computing watermarks

I guess we should renable the enabled local variable into something a
notch more descriptive, but that's something for -next.

The effect on my i945gme netbook is pretty severe amounts of underruns
- usually the very first pixel gets used for the entire screeen.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Haswell's DDI encoders have their own ->get_config callback and in

commit c6cd2ee2
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Oct 21 10:52:07 2013 +0300

    drm/i915/dp: workaround BIOS eDP bpp clamping issue

we've forgotten to replicate this hack. So let's do it that.

Note for backporters: The above commit and all it's depencies need to
be backported first.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049
Cc: stable@vger.kernel.org
Tested-by: NGökçen Eraslan <gokcen.eraslan@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the hardware does not support package C8, then do not even schedule
work to enable it. Thereby we can eliminate a bunch of dangerous work.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to hold the pc8 lock around toggling the value of gpu_idle.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We must have one to fill out the adjusted_mode.crtc_clock. And with
the tv encoder fixed up every encoder we have has a ->get_config
callback. So we can drop the checks.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this to properly fill in adjusted_mode.crtc_clock, otherwise
the state checker gets unhappy. This seems to have been forgotten in
the big clock rework in

commit 18442d08
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Sep 13 16:00:08 2013 +0300

    drm/i915: Fix port_clock and adjusted_mode.clock readout all over

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some BIOS just leak the forcewak bits, which we clean up.
Unfortunately this has been broken in

commit 521198a2
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Aug 23 16:52:30 2013 +0300

    drm/i915: sanitize forcewake registers on reset

To make this work both for resets and for BIOS takeover just add the
forcewake clearing call back to intel_uncore_early_sanitize.

We need to clear the forcewake in early sanitize so that the forcewak
dance in intel_uncore_init (to figure out whether we have mt or legacy
forcewake on ivb) works. That cleanup fits in nicely with the general
topic of early_sanitize to prepare for the very first mmio ops.

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: NJörg Otte <jrg.otte@gmail.com>
Cc: Jörg Otte <jrg.otte@gmail.com>
References: https://lkml.org/lkml/2013/11/16/40
Cc: stable@vger.kernel.org (for 3.12 only)
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 351aa566.

It breaks rc6 on at least one snb machine. Since we don't yet have a
report for ivb let's keep it there for now.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71656
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: erik@vontaene.de
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently they need the same treatment as primary planes. This fixes
modesetting failures because of stuck cursors (!) on Thomas' i830M
machine.

I've figured while at it I'll also roll it out for the ivb 3 pipe
version of this function. I didn't do this for i845/i865 since Bspec
says the update mechanism works differently, and there's some
additional rules about what can be updated in which order.
Tested-by: NThomas Richter <thor@math.tu-berlin.de>
Cc: stable@vger.kernel.org
Cc:  Thomas Richter <thor@math.tu-berlin.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We had been using a DMI table workaround to select the right
frequency for devices, but this is fragile and must be updated
with every new platform.

Instead the default case when VBT is missing is changed to use
120MHz clock for LVDS SSC for these generations.

The docs for 2010-Core, SandyBridge, and IvyBridge all indicate
that the reference frequency for LVDS is 120MHz:

"2010 Core"
http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf
page 38
Reference Frequency: 120MHz for CRT and LVDS.  100MHz for the FDI.

"2011 SandyBridge"
http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
page 33
Reference Frequency: 120MHz for CRT, HDMI, LVDS.  100MHz for the FDI.

"2012 IvyBridge"
http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf
page 27
Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI.
Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
[olof: Fixup for recent base, switched from if/else to single call]
Signed-off-by: NOlof Johansson <olof@lixom.net>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We've always been able to use either method on VLV, but it appears more
recent BIOSes only support the gen6 method, so switch over to that.

References: https://bugs.freedesktop.org/show_bug.cgi?id=71370Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We used to put the local sink and any downstream sinks to power down
mode at disable or dpms off using the DPCD SET_POWER register, until
this was broken by

commit e8cb4558
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 1 13:05:48 2012 +0200

    drm/i915/dp: convert to encoder disable/enable

Fix it.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

One last patch I keep forgetting to include.  Fix for EDID quirk
handling.  Been on the list and reviewed for several months now,
I just keep forgetting about it.

* 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux:
  drm/edid: compare actual vrefresh for all modes for quirks

Merge tag 'drm-intel-fixes-2013-11-12' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Just one patch to fix compile fail for CONFIG_ACPI=n. Figured I better
send this out quickly to minimize the broken build span. Otherwise no
bugfixes (besides some bdw stuff) anywhere in sight.

* tag 'drm-intel-fixes-2013-11-12' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915/opregion: fix build error on CONFIG_ACPI=n

The page-prot bit fix.

* 'ttm-next-3.13' of git://people.freedesktop.org/~thomash/linux:
  drm/ttm: Fix vma page_prot bit manipulation

A resource eviction fix, and a fix for compilation / sparse problems
from the previous pull.

* 'vmwgfx-next-3.13' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Fix a couple of compile / sparse warnings and errors
  drm/vmwgfx: Resource evict fixes

Fix a long-standing TTM issue where we manipulated the vma page_prot
bits while mmap_sem was taken in read mode only. We now make a local
copy of the vma structure which we pass when we set the ptes.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>

Fixes
 *) an implicit function declaration on mips,
 *) a defined but not used label on !CONFIG_INTEL_IOMMU
 *) Hopefully a couple of sparse warnings where we implicitly typecast
    integer to __le32 and vice versa.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

Fix an error message that was incorrectly blaming device resource id
shortage.

Also make sure we correctly catch resource eviction errors, that
could otherwise lead to evictable resources temporarily not being on the
LRU list.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org

The vrefresh field of the mode is 0 for most modes
fetched from the EDID (e.g., established timings).
When dealing with monitors that have a bogus preferred
mode, we may not always select the mode we want because
we compare the target refresh to the mode's vrefresh which
is 0 in a lot of cases.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

SDVO support for minnowboard

* 'gma500-next' of git://github.com/patjak/drm-gma500:
  drm/gma500/mrst: Add SDVO to output init
  drm/gma500/mrst: Don't blindly guess a mode for LVDS
  drm/gma500/mrst: Setup GMBUS for oaktrail/mrst
  drm/gma500/mrst: Replace WMs and chickenbits with values from EMGD
  drm/gma500/mrst: Add aux register writes to SDVO
  drm/gma500/mrst: Properly route oaktrail hdmi hooks
  drm/gma500/mrst: Add aux register writes when programming pipe
  drm/gma500/mrst: Add SDVO clock calculation
  drm/gma500: Add aux device support for gmbus
  drm/gma500: Add support for aux pci vdc device
  drm/gma500: Add chip specific sdvo masks
  drm/gma500: Add Minnowboard to the IS_MRST() macro

Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.

Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>