Just a single pll/crtc regression fix.

* 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux:
  radeon: fix pll/ctrc mapping on dce2 and dce3 hardware

This fix black screen on resume issue that some people are
experiencing. There is a bug in the atombios code regarding
pll/crtc mapping. The atombios code reverse the logic for
the pll and crtc mapping.

agd5f: drop unnecessary crtc id check, cc stable in case
we miss 3.7.

This fixes the root cause that was worked around by commits:
drm/radeon: allocate PPLLs from low to high
drm/radeon/dce3: switch back to old pll allocation order for discrete

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Inki writes:
This pull request fixes minor issues and includes code cleanup.

* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: Fix potential NULL pointer dereference in exynos_drm_encoder.c
  drm/exynos: Make exynos4/5_fimd_driver_data static
  drm/exynos: fix overlay updating issue
  drm/exynos: remove unnecessary code.
  drm/exynos: fix linux framebuffer address setting.

Daniel writes:
- Unbreak mbp retina, this time with a much more fine-grained approach
   (since the previous "completely ignore edp vbt bpp value" regressed some
   machines even after fixing a bug in our dp bw code).
- Disable cloning on sdvo. It just doesn't work (yeah took us a while to
   figure out), leading to jittery outputs in the best case.
- Revert rc6 for ilk again. It seems to help a few of the gpu hang
  reporters at least, and it's definitely the best we've got.
  Head-against-the-wall-banging is still ongoing for what really breaks
  (and how we can reproduce the non-rc6 hangs and how to reproduce on
  gen4).
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  Revert "drm/i915: enable rc6 on ilk again"
  drm/i915: do not default to 18 bpp for eDP if missing from VBT
  drm/i915: disable cloning on sdvo

Even with the cumulative set of ilk w/a, rc6 is demonstrably still
failing and causing GPU hangs as found by Peter Wu. So we need to disable
it again until it is stable.

This reverts

commit 456470eb583f063ee84c6818251e638598be0fb8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 8 23:35:40 2012 +0200

    drm/i915: enable rc6 on ilk again

and the follow-on

commit cd7988eea561a70a4f98e431c1395f913672d626
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Aug 26 20:33:18 2012 +0200

    drm/i915: disable rc6 on ilk when vt-d is enabled

Note: The situation around the gen4/5 gpu hangs that cropped up in 3.7
is rather strange. Most useful bisects have lead to

commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 20 11:40:46 2012 +0200

    drm/i915: Track unbound pages

or even later commits that affect the gem bo recycling, which all is
way past the point where we re-enabled rc6. But somehow
reverting/disabling those commits doesn't help, but disabling rc6 at
least helps for many hangs on ilk. Obviously it doesn't change
anything at all on gen4, and there are still strange issues left on
gen5 (which we unfortunately can't readily reproduce).

Also, the error_state signature of the hangs which can be fixed with
this patch look remarkably different to those which seem to be
unaffected by the rc6 settings: The rc6 hangs are in the ring,
somewhere in the MI_FLUSH/PIPE_CONTROL sequence to make ilk coherent,
wheras all the other hangs tend to be at a random point in the middle
of the user batch. So it could also be that we have different issues.

Until we grow more clue, this at least helps some users.

Reported-by: Peter Wu <lekensteyn@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added note with some more details about the gen4/5 3.7
gpu hang regression.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 500a8cc466a24e2fbc4c86ef9c6467ae2ffdeb0c
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Wed Jan 13 11:19:52 2010 +0800

    drm/i915: parse eDP panel color depth from VBT block

originally introduced parsing bpp for eDP from VBT, with a default of 18
bpp if the eDP BIOS data block is not present. Turns out that default seems
to break the Macbook Pro with retina display, as noted in

commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Aug 10 11:10:20 2012 +0200

    drm/i915: ignore eDP bpc settings from vbt

Since we can't ignore bpc settings from VBT completely after all, get rid
of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is
missing from VBT.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
[danvet: paste in the updated commit message from irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Check overlay_ops is not NULL as checked in the previous 'if' condition.
Fixes the following smatch error:
drivers/gpu/drm/exynos/exynos_drm_encoder.c:509 exynos_drm_encoder_plane_disable()
error: we previously assumed 'overlay_ops' could be null (see line 499)

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

Fixes the following sparse warnings:
drivers/gpu/drm/exynos/exynos_drm_fimd.c:65:25: warning:
symbol 'exynos4_fimd_driver_data' was not declared. Should it be static?
drivers/gpu/drm/exynos/exynos_drm_fimd.c:69:25: warning:
symbol 'exynos5_fimd_driver_data' was not declared. Should it be static?

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

Chagelog v2:
Move encoder's dpms updating into exynos_drm_encoder_commit
function because when crtc's dpms is updated, encoder's dpms
is updated also. This would induce the issue that encoder
isn't disabled after crtc is disabled.

Changelog v1:
This patch fixes a issue that overlay data aren't applied
to real hardware when dpms off goes to on after setcrtc
was requested like below,
    dpms off -> setcrtc -> dpms off -> dpms on

For this, it makes encoder's dpms to be updated when
setcrtc is requested.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

plane->fb will be set to new fb after update_plane callback is called
by drm_mode_set_plane()

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>