-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRRkrbAAoJEHm+PkMAQRiGy3oH/jrbHinYs0auurANgx4TdtWT
/WNajstKBqLOJJ6cnTR7sOqwOVlptt65EbbTs+qGyZ2Z2W/Lg0BMenHvNHo4ER8C
e7UbMdBCSLKBjAMKh1XCoZscGv4Exm8WRH3Vc5yP0Hafj3EzSAVLY1dta9WKKoQi
bh7D1ErUlbU1zczA1w5YbPF0LqFKRvyZOwebMCCAKAxv5wWAxmbcPNxVR4sufkjg
k6TkQ2ysgWivZAfy3tJYOcxiEu7ahpZVEuYdlZEJQXHRQUfoNljQlOp4BqKsYUai
5A0kaf2VpKay/7pkhvTfBBcF/jFJ68pYP6gQ2ThNdr0b5kOiAfMWj030Xyngnhg=
=iO9t
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc3' into drm-intel-next-queued
Backmerge so that I can merge Imre Deak's coalesced sg entries fixes,
which depend upon the new for_each_sg_page introduce in
commit a321e91b6d
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Feb 27 17:02:56 2013 -0800
lib/scatterlist: add simple page iterator
The merge itself is just two trivial conflicts:
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to set the 'allow force wake' bit to enable forcewake handling
later on.
v2: split from clock gating patch (Jani)
check for allowwakeack (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Once we thought we got semaphores working, we disabled kicking the ring
if hangcheck fired whilst waiting upon a ring as it was doing more harm
than good:
commit 4e0e90dcb8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Dec 14 13:56:58 2011 +0100
drm/i915: kicking rings stuck on semaphores considered harmful
However, life is never that easy and semaphores are still causing
problems whereby the value written by one ring (bcs) is not being
propagated to the waiter (rcs). Thus the waiter never wakes up and we
declare the GPU hung, which often has unfortunate consequences, even if
we successfully reset the GPU.
But the GPU is idle as it has completed the work, just didn't notify its
clients. So we can detect the incomplete wait during hang check and
probe the target ring to see if has indeed emitted the breadcrumb seqno
following the work and then and only then kick the waiter.
Based on a suggestion by Ben Widawsky.
v2: cross-check wait with iphdr. fix signaller calculation.
References: https://bugs.freedesktop.org/show_bug.cgi?id=54226
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To avoid this:
[ 256.798060] [drm] capturing error event; look for more information
in/sys/kernel/debug/dri/0/i915_error_state
Ben Widawsky identified that this regression has been introduced in
commit 2f86f19165
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Mon Jan 28 15:32:15 2013 -0800
drm/i915: Error state should print /sys/kernel/debug
...
[danvet: split up long line.] <----- he did it
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Pimp commit message with the regression note. Also, order
more brown paper bags, I've run out.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because the register does not exist on LPT. The interesting fact is
that reading/writing PCH_LVDS on LPT does *not* give us "unclaimed
register" messages, but the register value is always 0.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now it returns false for all platforms unless they're explicitly
listed on the function. There should be no real difference, except for
the fact that it now returns false on Haswell.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're starting to add many IS_HASWELL checks for the power well code,
so add a HAS_POWER_WELL macro to properly document that we're checking
for hardware that has the power down well.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflicts since some converted code was added by
not-yet merged patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when we hang the GPU. This solves "unclaimed
register" messages.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Future-proof by adding a gen >= 7 check in addition to the
!IS_HSW check from Paulo's original patch, suggested by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when capturing the error state. This solves some
"unclaimed register" messages on Haswell when we hang the GPU.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This solves some "unclaimed register" messages when there's a GPU hang
on Haswell.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add missing IS_VLV check as spotted by Ville Syrjälä.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our mode set sequence documentation says audio must be disabled first.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict since the first patch in this series isn't
applied yet. Also bikeshed commit message as suggested by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
v2:
- rewrote comment, thanks to Chris Wilson
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: add patch history log to commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This replaces the manual read/write routines in debugfs with the common
simple attribute helpers. Doing this gets rid of repeated copy/pasting
of copy_from_user and value formatting code.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Squash in follow-up fix from Kees Cook to fix u64 divides on
32bit platforms.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Regression fixes and oops fixes for nouveau.
* 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv50: use correct tiling methods for m2mf buffer moves
drm/nouveau: idle channel before releasing notify object
drm/nouveau: fix regression in vblanking
drm/nv50: encoder creation failure doesn't mean full init failure
Currently used only on original nv50, nvaa and nvac.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Unmapping it while it's still in use (e.g. by M2MF) can lead to page faults
and a lot of TRAP_M2MF spam in dmesg.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nv50_vblank_enable/disable got switched from NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is wrong.
4 << head is the correct value.
Fixes regression with vblanking since 1d7c71a3e2 "drm/nouveau/disp: port vblank handling to event interface"
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit ac24c2204a ("drm/tegra: Use generic
HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
statement for that symbol is a nop. Drop it.
What was needed to use HDMI functionality was to select HDMI (which this
entry already did through depending on DRM) and to include linux/hdmi.h
(which this commit also did).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Renesas boards were consistently defaulting to the 1024x768 resolution,
regardless of the native resolution of the monitor plugged in. It was
determined that the EDID of the monitor was not being read. Since the
DAC is a shared line, in order to read from or write to it we must take
control of the DAC clock. This can be done by setting the proper
register to one.
This bug fix sets the register MGA1064_GEN_IO_CTL2 to one. The DAC
control line can be used to determine whether or not a new monitor has
been plugged in. But since the hotplug feature is not one we will
support, it has been decided to simply leave the register set to one.
Signed-off-by: Julia Lemire <jlemire@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A monitor or a user could request a resolution greater than the
available VRAM for the backing framebuffer. This change checks the
required framebuffer size against the max VRAM size and rejects modes
if they are too big. This change can also remove a mode request passed
in via the video= parameter.
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The MIP_ADDRESS state has 2 meanings. If the texture has one sample
per pixel, it's a pointer to the mipmap chain. If the texture has
multiple samples per pixel, it's a pointer to FMASK, a metadata buffer
needed for reading compressed MSAA textures. The mipmap
alignment rules do not apply to FMASK.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The MC is mostly likely busy (e.g., display requests), not hung
so no need to reset it. Doing an MC reset is tricky and not
particularly reliable. Fixes hangs in certain cases.
Reported-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
vbios values are wrong leading to colors that are
too bright. Use the default values instead.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Avoids splatter if the interrupt handler is not registered due
to acceleration being disabled.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
A bunch of fixes, nothing truely horrible:
- Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs
and subsequent fallout (Paulo)
- Fixup off-by-one in our hsw id table (Kenneth)
- Fixup ilk rc6 support (disabled by default), regression introduced in
3.8
- g4x plane w/a from Egbert Eich
- gen2/3/4 dpms suspend/standy fixes for VGA outputs from Patrik Jakobsson
- Workaround dying ivb machines with less aggressive rc6 values (Stéphane
Marchesin)
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Turn off hsync and vsync on ADPA when disabling crt
drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits
drm/i915: also disable south interrupts when handling them
drm/i915: enable irqs earlier when resuming
drm/i915: Increase the RC6p threshold.
DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.
drm/i915: Fix Haswell/CRW PCI IDs.
drm/i915: Don't clobber crtc->fb when queue_flip fails
drm/i915: wait_event_timeout's timeout is in jiffies
drm/i915: Fix missing variable initilization
Allows us to detect eDP panels that may not have the hotplug pin wired up.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It uses the same bit definitions.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix up a couple of places where we messed with PCH bits on VLV.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was omitted from
commit b7884eb45e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jun 4 11:18:15 2012 +0200
drm/i915: hold forcewake around ring hw init
which introduced the ->has_force_wake flag.
Note that this only enables the above w/a hack.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Put some interesting stuff into the empty commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to PRM we need to disable hsync and vsync even though ADPA is
disabled. The previous code did infact do the opposite so we fix it.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Tested-by: max <manikulin@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend
becoming standby and vice versa. Fixed by swapping their bit position.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From the docs:
"IIR can queue up to two interrupt events. When the IIR is cleared,
it will set itself again after one clock if a second event was
stored."
"Only the rising edge of the PCH Display interrupt will cause the
North Display IIR (DEIIR) PCH Display Interrupt even bit to be set,
so all PCH Display Interrupts, including back to back interrupts,
must be cleared before a new PCH Display interrupt can cause DEIIR
to be set".
The current code works fine because we don't get many interrupts, but
if we enable the PCH FIFO underrun interrupts we'll start getting so
many interrupts that at some point new PCH interrupts won't cause
DEIIR to be set.
The initial implementation I tried was to turn the code that checks
SDEIIR into a loop, but we can still get interrupts even after the
loop is done (and before the irq handler finishes), so we have to
either disable the interrupts or mask them. In the end I concluded
that just disabling the PCH interrupts is enough, you don't even need
the loop, so this is what this patch implements. I've tested it and it
passes the 2 "PCH FIFO underrun interrupt storms" I can reproduce:
the "ironlake_crtc_disable" case and the "wrong watermarks" case.
In other words, here's how to reproduce the problem fixed by this
patch:
1 - Enable PCH FIFO underrun interrupts (SERR_INT on SNB+)
2 - Boot the machine
3 - While booting we'll get tons of PCH FIFO underrun interrupts
4 - Plug a new monitor
5 - Run xrandr, notice it won't detect the new monitor
6 - Read SDEIIR and notice it's not 0 while DEIIR is 0
Q: Can't we just clear DEIIR before SDEIIR?
A: It doesn't work. SDEIIR has to be completely cleared (including the
interrupts stored on its back queue) before it can flip DEIIR's bit to
1 again, and even while you're clearing it you'll be getting more and
more interrupts.
Q: Why does it work by just disabling+enabling the south interrupts?
A: Because when we re-enable them, if there's something on the SDEIIR
register (maybe an interrupt stored on the queue), the re-enabling
will make DEIIR's bit flip to 1, and since we'll already have
interrupts enabled we'll get another interrupt, then run our irq
handler again to process the "back" interrupts.
v2: Even bigger commit message, added code comments.
Note that this fixes missed dp aux irqs which have been reported for
3.9-rc1. This regression has been introduced by switching to
irq-driven dp aux transactions with
commit 9ee32fea5f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 13:53:48 2012 +0100
drm/i915: irq-drive the dp aux communication
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18588.html
References: https://lkml.org/lkml/2013/2/26/769
Tested-by: Imre Deak <imre.deak@intel.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Pimp commit message with references for the dp aux irq
timeout regression this fixes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need it to restore the ilk rc6 context, since the gpu wait no
requires interrupts. But in general having interrupts around should
help in code sanity, since more and more stuff is interrupt driven.
This regression has been introduced in
commit 3e9605018a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 27 16:22:54 2012 +0000
drm/i915: Rearrange code to only have a single method for waiting upon the ring
Like in the driver load code we need to make sure that hotplug
interrupts don't cause havoc with our modeset state, hence block them
with the existing infrastructure. Again we ignore races where we might
loose hotplug interrupts ...
Note that the driver load part of the regression has already been
fixed in
commit 52d7ecedac
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 21:03:22 2012 +0100
drm/i915: reorder setup sequence to have irqs for output setup
v2: Add a note to the commit message about which patch fixed the
driver load part of the regression. Stable kernels need to backport
both patches.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691
Cc: stable@vger.kernel.org (for 3.8 only, plese backport
52d7ecedac first)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reported-and-Tested-by: Ilya Tumaykin <itumaykin@gmail.com>
Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some
reason this avoids the gen6_gt_check_fifodbg.isra warnings and
associated GPU lockups, which makes my ivy bridge machine stable.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On error, this represents the state of the currently running context at
the time it was loaded.
Unfortunately, since we're hung and can't switch out the context this
may not tell us too much about the most current state of the context,
but does give clues about what has happened since loading.
Thanks to recent doc updates, we have a little more confidence regarding
what is actually in this memory, and perhaps it will help us gain more
insight into certain bugs. AFAICT, the most interesting info is in the
first page. To save space, we only capture the first page. In the
future, we might want to dump more.
Sample of the relevant part of error state:
render ring --- HW Context = 0x01b20000
[0000] 00000000 1100105f 00002028 ffff0880
[0010] 0000209c feff4040 000020c0 efdf0080
[0020] 00002178 00000001 0000217c 00145855
[0030] 00002310 00000000 00002314 00000000
v2: Move error collection to the ring error code
Change format of dump to not confuse intel_error_decode (Chris)
Put the context error object with the others (Chris)
Don't search bound_list instead of active_list (chris)
v3: extract and flatten context recording (daniel)
checkpatch related fixes for the copypasta in debugfs
v4: bug in v3 (Daniel)
- if ((ring->id == RCS) && error->ccid)
+ if ((ring->id != RCS) || !error->ccid)
References: https://bugs.freedesktop.org/show_bug.cgi?id=55845
Reviewed-by (v2): Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Bikeshed away the redudant parenthese around ring->id != RCS]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bits used only on HDMI mode now have HDMI_ prefix instead of SDVO_.
The COLOR_FORMAT bits now have prefixes (and the 12bpc bit is for HDMI
only).
Notice that this patch uncovers a bug on the SDVO code: the
COLOR_RANGE_16_235 bit can only be used if the port is in TMDS mode,
not SDVO mode. This will have to be fixed in a later patch.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since they're all the same register, leave all the #defines at the
same place, organized by Gen and also specify which bits are used by
only a specific port or encoding.
Also remove a few unused duplicates and adjust indentation.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some HDMI registers can be used for SDVO, so saying "HDMIB" should be
the same as saying "SDVOB" for a given HW generation. This was not
true and led to confusions and even a regression.
Previously we had:
- SDVO{B,C} defined as the Gen3+ registers
- HDMI{B,C,D} and PCH_SDVOB defined as the PCH registers
But now:
- SDVO{B,C} became GEN3_SDVO{B,C} on SDVO code
- SDVO{B,C} became GEN4_HDMI{B,C} on HDMI code
- HDMI{B,C,D} became PCH_HDMI{B,C,D}
- PCH_SDVOB is still the same thing
v2: Rebase (v1 was sent in May 2012).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commented out and unneeded.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Actually use num_pages (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On G45 some low res modes (800x600 and 1024x768) produce a blank
screen when the display plane is enabled with with cursor plane
off.
Experiments showed that this issue occurred when the following
conditions were met:
a. a previous mode had the cursor plane enabled (Xserver).
b. this mode or the previous one was using self refresh. (Thus
the problem was only seen with low res modes).
The screens lit up as soon as the cursor plane got enabled.
Therefore the blank screen occurred only in console mode, not
when running an Xserver.
It also seemed to be necessary to disable self refresh while briefly
enabling the cursor plane.
Signed-off-by: Egbert Eich <eich@suse.com>
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=61457
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: drop spurious whitespace change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
