<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/gpu, branch v3.7</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage</title>
<updated>2012-12-10T19:03:05+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-12-10T18:51:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=caf491916b1c1e939a2c7575efb7a77f11fc9bdf'/>
<id>caf491916b1c1e939a2c7575efb7a77f11fc9bdf</id>
<content type='text'>
This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and
d7c3b937bdf45f0b844400b7bf6fd3ed50bac604.

This is a revert of a revert of a revert.  In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.

It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all.  We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.

When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation.  That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.

So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake.  Let's hope we never revisit
this mistake again - and certainly not this many times ;)

Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and
d7c3b937bdf45f0b844400b7bf6fd3ed50bac604.

This is a revert of a revert of a revert.  In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.

It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all.  We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.

When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation.  That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.

So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake.  Let's hope we never revisit
this mistake again - and certainly not this many times ;)

Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux</title>
<updated>2012-11-28T06:51:10+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@gmail.com</email>
</author>
<published>2012-11-28T06:51:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e548a83c34806b8bc2c55f52d3bc481a13a3829e'/>
<id>e548a83c34806b8bc2c55f52d3bc481a13a3829e</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>radeon: fix pll/ctrc mapping on dce2 and dce3 hardware</title>
<updated>2012-11-27T21:59:03+00:00</updated>
<author>
<name>Jerome Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2012-11-27T21:12:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fc58acdbf153f12783b80cb19c04cc9de121b518'/>
<id>fc58acdbf153f12783b80cb19c04cc9de121b518</id>
<content type='text'>
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 &lt;jglisse@redhat.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jglisse@redhat.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos</title>
<updated>2012-11-27T04:41:37+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@gmail.com</email>
</author>
<published>2012-11-27T04:41:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=64b1e1bad7f49f32e4036a53dbe1de2b76a43eac'/>
<id>64b1e1bad7f49f32e4036a53dbe1de2b76a43eac</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel</title>
<updated>2012-11-27T04:40:13+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@gmail.com</email>
</author>
<published>2012-11-27T04:40:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=efc15e04886d4fdc57f580ec4ae049aece8973e7'/>
<id>efc15e04886d4fdc57f580ec4ae049aece8973e7</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "drm/i915: enable rc6 on ilk again"</title>
<updated>2012-11-25T19:53:52+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2012-11-10T10:00:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6567d748c4e94e3481e523803ec07ebd825c80d6'/>
<id>6567d748c4e94e3481e523803ec07ebd825c80d6</id>
<content type='text'>
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 &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;chris@chris-wilson.co.uk&gt;
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 &lt;lekensteyn@gmail.com&gt;
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
[danvet: Added note with some more details about the gen4/5 3.7
gpu hang regression.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;chris@chris-wilson.co.uk&gt;
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 &lt;lekensteyn@gmail.com&gt;
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
[danvet: Added note with some more details about the gen4/5 3.7
gpu hang regression.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: do not default to 18 bpp for eDP if missing from VBT</title>
<updated>2012-11-22T20:34:32+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2012-11-12T12:33:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9a30a61f3516871c5c638fd7c025fbaa11ddf7fe'/>
<id>9a30a61f3516871c5c638fd7c025fbaa11ddf7fe</id>
<content type='text'>
commit 500a8cc466a24e2fbc4c86ef9c6467ae2ffdeb0c
Author: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
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 &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;jani.nikula@intel.com&gt;
Tested-by: Henrik Rydberg &lt;rydberg@euromail.se&gt;
[danvet: paste in the updated commit message from irc.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 500a8cc466a24e2fbc4c86ef9c6467ae2ffdeb0c
Author: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
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 &lt;daniel.vetter@ffwll.ch&gt;
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 &lt;jani.nikula@intel.com&gt;
Tested-by: Henrik Rydberg &lt;rydberg@euromail.se&gt;
[danvet: paste in the updated commit message from irc.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/exynos: Fix potential NULL pointer dereference in exynos_drm_encoder.c</title>
<updated>2012-11-22T08:55:17+00:00</updated>
<author>
<name>Sachin Kamat</name>
<email>sachin.kamat@linaro.org</email>
</author>
<published>2012-11-19T09:20:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c69d5276704e1a9c771de57c0a2e7b69ea3ea578'/>
<id>c69d5276704e1a9c771de57c0a2e7b69ea3ea578</id>
<content type='text'>
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 &lt;sachin.kamat@linaro.org&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sachin.kamat@linaro.org&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/exynos: Make exynos4/5_fimd_driver_data static</title>
<updated>2012-11-22T08:55:17+00:00</updated>
<author>
<name>Sachin Kamat</name>
<email>sachin.kamat@linaro.org</email>
</author>
<published>2012-11-19T09:52:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=77b1c0362ffdb11128590a7248f3f8c434ab42f2'/>
<id>77b1c0362ffdb11128590a7248f3f8c434ab42f2</id>
<content type='text'>
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 &lt;sachin.kamat@linaro.org&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sachin.kamat@linaro.org&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/exynos: fix overlay updating issue</title>
<updated>2012-11-22T08:55:17+00:00</updated>
<author>
<name>Inki Dae</name>
<email>inki.dae@samsung.com</email>
</author>
<published>2012-11-14T11:41:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ffe9955a741a2742cc517245b2219b61cc6dde28'/>
<id>ffe9955a741a2742cc517245b2219b61cc6dde28</id>
<content type='text'>
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 -&gt; setcrtc -&gt; dpms off -&gt; dpms on

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

Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 -&gt; setcrtc -&gt; dpms off -&gt; dpms on

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

Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
