My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work. Setting i915.semaphore=0 fixes it.
Semaphores were disabled in a1656b9090
in 2.6.38 and were re-enabled by
commit 47ae63e0c2
Merge: c59a333467cffb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 7 12:32:44 2011 +0000
Merge branch 'drm-intel-fixes' into drm-intel-next
Apply the trivial conflicting regression fixes, but keep GPU semaphores
enabled.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem_execbuffer.c
(It's worth noting that the offending change is i915_drv.c,
which is not a conflict.)
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the requested device is already active, ignore the request.
This restores the original behaviour of the interface. The change was
probably an unintended side effect of
commit 66b37c6777 vga_switcheroo: split switching into two stages
which did not take into account to duplicate the !active check in the split-off
stage2.
Fix this by factoring that check out of stage1 into the debugfs_write routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=34252
Reported-by: Igor Murzov <e-mail@date.by>
Tested-by: Igor Murzov <e-mail@date.by>
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ibex Peak and CougarPoint already require a different setting (added
here), and future chips will likely follow that precedent.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Some of the bits have changed, including one we were setting that enables
a VGA test mode, preventing pipe B from working at all. So add a new
IVB specific function with the right bits.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
They have been moved from the ringbuffer groups to their own group it
looks like. Fixes GPU hangs on gnome startup.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The registers are the same as on Sandybridge. Fixes scrambled display
in X when it does software drawing to the GTT, and scans the results
out as tiled.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is once less place to miss a new INTEL_INFO(dev)->gen update now.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This helps contain the mess to init_display() instead.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a little less confusing than relying on the implicit zeroing of
the dev_priv.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
There are several variants, set feature bits appropriately for both
mobile and desktop parts.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We can treat PantherPoint as CougarPoint as far as display goes.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Use Sandy Bridge paths in a few places.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Treat Ivy Bridge like previous chips as far as flip submission is
concerned.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Add new interrupt handling functions for Ivy Bridge.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Not fully tested.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
A0 stepping chips need to use manual training, but the bits have all
moved. So fix things up so we can at least train FDI for VGA links.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Treat it like Ironlake and Sandy Bridge.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Ivy Bridge has a similar split display controller to Sandy Bridge, so
use HAS_PCH_SPLIT. And gen7 also has the pipe control instruction, so
use HAS_PIPE_CONTROL as well.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Note: IS_GEN* are for render related checks. Display and other checks
should use IS_MOBILE, IS_$CHIPSET or test for specific features.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This makes the Ironlake+ code trivial and generally simplifies things.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Set the IRQ handling functions in driver load so they'll just be used
directly, rather than branching over most of the code in the chipset
functions.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Rather than branching in ironlake_pch_enable, add a new train_fdi
function to the display function pointer struct and use it instead.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Forcewake needs to register itself with drm to use the remove function.
The file also should be read only.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
On rev <= 1.1 tables, the offset is absolute,
on newer tables, it's relative.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=700326
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The location of MC_ARB_RAMCFG changed on fusion.
I've diffed all the other regs in evergreend.h and this
is the only other reg that changed.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 49183b2818.
Quoth Franz Melchior:
"This patch introduces a bug on my infamous "Acer Travelmate
5735Z-452G32Mnss": when KMS takes over, the frame buffer contents get
completely garbled up on screen, with colored stripes and unreadable
text (photo on request). Only when X11 is started, the screen gets
restored again. Closing and re-opening the lid partly cures the
mess, too: it makes the font readable, though horizontally stretched."
Acked-by: Keith Packard <keithp@keithp.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Xen changes were using DMA_ERROR_CODE which isn't defined on a few
platforms, however we reverted the Xen patch that caused use to try and
use this code path earlier in 2.6.39 cycle, so for now lets just force
the code to never take this path and allow it to build again on alpha.
The proper long term answer is probably to store if the dma_addr has
been assigned to alongside the dma_addr in the higher level code,
though I think Thomas wanted to rewrite most of this anyways properly.
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The TCC disable setup was incorrect. This
prevents the GPU from hanging when draw commands
are issued.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We are accessing totally the wrong struct in this case, and putting
uninitialised values into the GPU, which it doesn't like unsurprisingly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
forcewake is controlled by the open and close of the debugfs file. This
assures that buggy applications cannot cause the GT to stay on forever.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
The render P-state handling code requires reading from a GT register.
This means that FORCEWAKE must be written to, a resource which is shared
and should be protected by struct_mutex. Hence we can not manipulate
that register from within the interrupt handling and so must delegate
the task to a workqueue.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Found by the new strict checking for the mutex being held whilst
manipulating the forcewake status.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Provide a reference count to track the forcewake state of the GPU and
give a safe mechanism for userspace to wake the GT. This also potentially
saves a UC read if the GT is known to be awake already.
The reference count is atomic, but the register access and hardware wake
sequence is protected by struct_mutex.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Moved the macros around to properly do reads and writes for the given
GPU. This is to address special requirements for gen6 (SNB) reads and
writes.
Registers in the range 0-0x40000 on gen6 platforms require special
handling. Instead of relying on the callers to pick the registers
correctly, move the logic into the read and write functions.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the outputs are active and continuing to access the GATT when we
teardown the PTEs, then there is a potential for us to hang the GPU.
The hang tends to be a PGTBL_ER with either an invalid host access or
an invalid display plane fetch.
v2: Reorder IRQ initialisation to defer until after GEM is setup.
Reported-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (855GM)
Tested-by: Pekka Enberg <penberg@kernel.org>
# note that this doesn't fix the underlying problem of the
PGTBL_ER and pipe underruns being reported immediately upon
init on his 965GM MacBook
Reported-and-tested-by: Rick Bramley <richard.bramley@hp.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35635
Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36048
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Rely on the GPU snooping into the CPU cache for appropriately bound
objects on MI_FLUSH. Or perhaps one day we will have a cache-coherent
CPU/GPU package...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
... to clarify just how we use it inside the driver and remove the
confusion of the poorly matching agp_type names. We still need to
translate through agp_type for interface into the fake AGP driver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
Currently this is only useful for the rc6 stuff. But this would also be
useful when I finally get around to the logical context + ppgtt stuff.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
For debug & testing.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is a race condition between setting PWRCTXA and executing
MI_SET_CONTEXT. PWRCTXA must not be set until a valid context has been
written (or else the GPU could possible go into rc6, and return to an
invalid context).
Reported-and-Tested-by: Gu Rui <chaos.proton@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Added a new function which waits for the ringbuffer space to be equal to
(total - 8). This is the empty condition of the ringbuffer, and
equivalent to head==tail.
Also modified two users of this functionality elsewhere in the code.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the failure cases during rc6 initialization, both the power context
and render context may get !refcount without holding struct_mutex.
However, on rc6 disabling, the lock is held by the caller.
Rearranged the locking so that it's safe in both cases.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
They're used in one place, and not providing any descriptive value,
with their names just being approximately the conjunction of the
struct name and the struct field.
This diff was produced with gcc -E, copying the new struct definitions
out, moving a couple of the old comments into place in the new
structs, and reindenting.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We used to have these from the product of (pch, non-pch) * (pipe a,
pipe b). Now we can just use the nice per-pipe reg macros in the
split out crtc_mode_sets.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
While g4x had DP, eDP came with Ironlake, so we don't need that code here.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This path, which shouldn't be *that* complicated, is now so littered
with per-chipset tweaks that it's hard to trace the order of what
happens. HAS_PCH_SPLIT() is the most radical change across chipsets,
so it seems like a natural split to simplify the code.
This first commit just copies the existing code without changing
anything.
v2: updated to track removal of call to intel_enable_plane from i9xx_crtc_mode_set
Signed-off-by: Eric Anholt <eric@anholt.net>
Hella-acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to ensure that we feed valid memory into the display plane
attached to the pipe when switching the pipe on. Otherwise, the display
engine may read through an invalid PTE and so throw an PGTBL_ER
exception.
As we need to perform load detection before even the first object is
allocated for the fbdev, there is no pre-existing object large enough
for us to borrow to use as the framebuffer. So we need to create one
and cleanup afterwards. At other times, the current fbcon may be large
enough for us to borrow it for duration of load detection.
Found by assert_fb_bound_for_plane().
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
As we now never attempt to steal a crtc for load detection, we either
set a mode on a new pipe, or change the dpms mode on an existing pipe.
Never both, so we can simplify the code slightly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
As we only allow the use of a disabled CRTC, we don't need to handle the
case where we are reusing an already enabled pipe.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
... and the no longer relevant comment. The code ceased stealing a pipe
for load detection a long time ago.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Keep all the state required for undoing and restoring the previous pipe
configuration together in a single struct passed from
intel_get_load_detect_pipe() to intel_release_load_detect_pipe() rather
than stuffing them inside the common encoder structure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Check the return value from drm_crtc_set_mode(), report the failure
via a debug message and propagate the error back to the caller. This
prevents us from blissfully continuing to do the load detection on a
disabled pipe. Fortunately actual failure for modesetting is very rare,
and reported failures even rarer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
... and so remove the confusion as to whether to use the returned crtc
or intel_encoder->base.crtc with the subsequent load-detection. Even
though they were the same, the two instances of load-detection code
disagreed over which was the more correct.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Required so that we don't obliterate the queue if initialising the
rings after the global IRQ handler is installed.
[Jesse, you recently looked at refactoring the IRQ installation
routines, does moving the initialisation of ring buffer data structures away
from that routine make sense in your grand scheme?]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915/lvds: Only act on lid notify when the device is on
drm/i915: fix intel_crtc_clock_get pipe reads after "cleanup cleanup"
drm/i915: Only enable the plane after setting the fb base (pre-ILK)
drm/i915/dp: Be paranoid in case we disable a DP before it is attached
drm/i915: Release object along create user fb error path
If we're using vga switcheroo, the device may be turned off
and poking it can return random state. This provokes an OOPS fixed
separately by 8ff887c847 (drm/i915/dp: Be paranoid in case we disable a
DP before it is attached). Trying to use and respond to events on a
device that has been turned off by the user is in principle a silly thing
to do.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
Despite the fixes in 548f245ba6 (drm/i915: fix per-pipe reads after
"cleanup"), we missed one neighbouring read that was mistakenly replaced
with the reg value in 9db4a9c (drm/i915: cleanup per-pipe reg usage).
This was preventing us from correctly determining the mode the BIOS left
the panel in for machines that neither have an OpRegion nor access to
the VBT, (e.g. the EeePC 700).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
When enabling the plane, it is helpful to have already pointed that
plane to valid memory or else we may incur the wrath of a PGTBL_ER.
This code preserved the behaviour from the bad old days for unknown
reasons...
Found by assert_fb_bound_for_plane().
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
* korg/drm-nvidia-switch-fixes:
mxm/wmi: add MXMX interface entry point.
nouveau: add optimus detection to DSM code.
vgaarb: use bridges to control VGA routing where possible.
nouveau/acpi: hook up to the MXM method for mux switching.
platform/x86: add MXM WMI driver.
The virtual i2c to real i2c channel mappings weren't setting
the right id in some cases.
Spotted by: Andrew Randrianasulu
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
if object pin or object lookup in radeon_cursor_set fail, the function
could leave inconsistent mouse width and hight values in radeon_crtc
fixed by moving cursor width and height assignments after all
checks have passed
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The looping helper didn't do anything due to a superficial
semicolon. Furthermore one of the two dump functions suffered
from copy&paste fail.
While staring at the code I've also noticed that the replace
helper (currently unused) is a bit broken.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we switch the display mux, also switch
the i2c mux. Also use the start and finish
methods to let the sbios know that the switch
is happening.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=35398
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
NV40 and older cards (pre NV50) reserve a vram bo for the vga memory at
card init. This bo is then freed at card shutdown. The problem is that
the ttm bo vram manager was already freed. So a crash occurs when the
vga bo is freed. The fix is to free the vga bo prior to freeing the ttm
bo vram manager. There might be other solutions but this seemed the
simplest to me.
Signed-off-by: Jimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Given that the hardware may be left in a random condition by the BIOS,
it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
without us ever enabling/attaching the DP encoder to a pipe. Thus
causing a NULL deference when we attempt to wait for a vblank on that
crtc.
Reported-and-tested-by: Bryan Christ <bryan.christ@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456
Reported-and-tested-by: Bo Wang <bo.b.wang@intel.com>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
Reported-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
This is unbalanced and probably more fitting for the client
to take care of. Remove it.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So in a lot of modern systems, a GPU will always be below a parent bridge that won't share with any other GPUs. This means VGA arbitration on those GPUs can be controlled by using the bridge routing instead of io/mem decodes.
The problem is locating which GPUs share which upstream bridges. This patch attempts to identify all the GPUs which can be controlled via bridges, and ones that can't. This patch endeavours to work out the bridge sharing semantics.
When disabling GPUs via a bridge, it doesn't do irq callbacks or touch the io/mem decodes for the gpu.
Signed-off-by: Dave Airlie <airlied@redhat.com>
this hooks up nouveau to the MXM mux switching method.
With this in place I can switch the LVDS MUX on my T410s,
I expect we need a bit more work for other laptops.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix the vbios mapping and only add the actual
buses that the cards have. The existing code was
mostly correct. Just clean up a few cases on r2xx/r3xx
and document that buses the hw actually has.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The most common use of the radeon i2c buses is for ddc.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The previous commit to move the parsing into the core drm created a
new situation and a soft dependency on the CONFIG_FB. We really don't
want to make this a hard dependency so just wrap the one place that
actually needs an fb symbol.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Out of the entire GART/VM subsystem, the hw designers changed
the location of 3 regs.
v2: airlied: add parameter for userspace to work from.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the least-bad behaviour. It means that we signal the
vblank event before it actually happens, but since we're disabling
vblanks there's no guarantee that it will *ever* happen otherwise.
This prevents GL applications which use WaitMSC from hanging
indefinitely.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since fafcf94e2b introduced an edid size, it seems to have broken this path.
This manifest as oops on T500 Lenovo laptops with dual graphics primarily.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33812
cc: stable@kernel.org
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the absence of configuration data for providing the fixed mode for
a panel, I would like to be able to pass such modes along a separate
module paramenter. To do so, I then need to parse a modeline from a
string, which drm is already capable of. Export that capability to the
drivers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
and fix fallout.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reduce drm text size ~1% by using drm_err and
printf extension %pV to emit error messages.
Remove unused macro DRM_MEM_ERROR.
$ size drivers/gpu/drm/built-in.o*
text data bss dec hex filename
361159 9663 256 371078 5a986 drivers/gpu/drm/built-in.o.new
365416 9663 256 375335 5ba27 drivers/gpu/drm/built-in.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:
[ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[ 17.772458] Hardware name: Latitude E6400
[ 17.772460] Modules linked in: ....
[ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8
[ 17.772584] Call Trace:
[ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82
[ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: Frederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
[airlied: tweaked to fix inter-patch dependency]
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
i915 calls the panic handler function on last close to reset the modes,
however this is a really bad idea for multi-gpu machines, esp shareable
gpus machines. So add a new entry point for the driver to just restore
its own fbcon mode.
v2: move code into fb helper, fix panic code to block mode change on
powered off GPUs.
[airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx
so really I signed it off twice ;-).]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Multi-gpu/switcheroo relies on this option to get the console on the
correct GPU at bootup, some distros enable it but it seems some get
it wrong.
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
agp: fix arbitrary kernel memory writes
agp: fix OOM and buffer overflow
drm/radeon/kms: fix IH writeback on r6xx+ on big endian machines
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915: Initialise g4x watermarks for disabled pipes
drm/i915: Sanitize the output registers after resume
drm/i915/tv: Fix modeset flickering introduced in 7f58aabc3
drm/i915/tv: Only poll for TV connections
drm/i915/tv: Remember the detected TV type
Commit 73412c3854 ("drm/nouveau: allocate
kernel's notifier object at end of block") intended to align end of
notifier block to page boundary, but start of block was miscalculated
to be off by -16 bytes. Fix it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes,
so after commit 73412c3854 ("drm/nouveau: allocate
kernel's notifier object at end of block") we started to overwrite some memory
after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't
matter it was a value in bytes).
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Reported-by: Nigel Cunningham <lkml@nigelcunningham.com.au>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Pekka Paalanen <pq@iki.fi>
Cc: stable@kernel.org [2.6.38]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Wasn't aware they even existed, apparently they do! They're actually
AGP chips with a bridge as far as I can tell, which puts them in the
same boat as nv40/nv45.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes a possible lock ordering reversal between context_switch_lock
and ramin_lock.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This patch fixes two issues:
- A disabled crtc does not use any lb, so return 0 for
lb size. This makes the display priority calculation
more exact.
- Only use 1/2 and whole lb partitions. Using smaller
partitions can cause underflow to one of the displays
if you have multiple large displays on the same lb.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=34534
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sometimes the i2c test in i2c_bit_add_bus fails
if this happens we fail to register the i2c adapter and
eventually fail to add the connector. If i2c fails,
add the connector to the user can at least force
it on.
Note that some distros set i2c-algo-bit.bit_test to 1 by
default which sometimes fails preventing the ddc i2c adapter
from being added. The i2c adapter works even if the bit test
fails, probably due to pre/post_xfer not getting called in
the test_bit function. I have another patch to follow
up on that.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=36221
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were using uninitialised watermarks values for disabled pipes which
were combined into a single WM register and so corrupting the values for
the enabled pipe and upsetting the display hardware.
Reported-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 0a0883c843.
this was in my tree by accident, I meant to rebase it out and
didn't realise in time.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 69a07f0b11.
We've tracked a number of problems back to this, and Thomas
thinks we should redesign this for .40/41 anyways so I'm
happy to revert it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
fix Kconfig warning:
(DRM_I915 && STUB_POULSBO) selects ACPI_VIDEO which has unmet direct dependencies
(ACPI && X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL && INPUT)
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Change vddci as well as vddc when changing power modes
on evergreen/ni. Also, properly set vddci on boot up
for ni cards. The vbios only sets the limited clocks
and voltages on boot until the mc ucode is loaded. This
should fix stability problems on some btc cards.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is needed for setting voltages other than vddc.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
btc and cayman asics use the same callback for
pcie port registers.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Apparently only rv515 asics need the workaround
added in f24d86f1a4
(drm/radeon/kms: fix resume regression for some r5xx laptops).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=34709
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
As per Konrad's original patch, the dummy page used
by the gart code and allocated in radeon_gart_init()
was not freed properly in radeon_gart_fini().
At the same time r6xx and newer allocated and freed the
dummy page on their own. So to do Konrad's patch one
better, just remove the allocation and freeing of the
dummy page in the r6xx, 7xx, evergreen, and ni code and
allocate and free in the gart_init/fini() functions for
all asics.
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Similar to booting, we need to inspect the state left by the BIOS and
remove any conflicting bits before we take over. The example reported by
Seth Forshee is very similar to the bug we encountered with the state left
by grub2, that the crtc pipe<->planning mapping was reversed from our
expectations and so we failed to turn off the outputs when booting or,
in this case, resuming. This may be in fact the same bug, but triggered
at resume time.
This patch rearranges the code we already have to clear up the
conflicting state upon init and calls it from reset (which is called
after we have lost control of the hardware, i.e. along both the boot and
resume paths) instead.
Reported-and-tested-by: Seth Forshee <seth.forshee@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The tidy ups in 7f58aabc36 ("drm/i915:
cleanup per-pipe reg usage") changed intel_crtc->plane to intel_crtc->pipe in
intel_tv_mode_set(). This caused the screen to quickly turn off before
returning whenever modesetting/mode probing took place on my 915GM EeePC
900 creating a flickering effect. This patch changes intel_crtc->pipe back
to intel_crtc->plane which solves the problem for me.
References: https://bugs.freedesktop.org/show_bug.cgi?id=35903
Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Humbly-acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
As a probe for a TV connection modifies the TV_CTL register, it causes a
loss of sync and a regular glitch on the output. This is highly
undesirable when using the TV, so only poll for TV connections and wait
for an explicit query for detecting the disconnection event.
Reported-by: Mathew McKernan <matmckernan@rauland.com.au>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977
Signed-off-by: Mathew McKernan <matmckernan@rauland.com.au>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
During detect() we would probe the connection bits to determine if
there was a TV attached, and what video input type (Component, S-Video,
Composite, etc) to use. However, we promptly discarded this vital bit of
information and never propagated it to where it was used to determine
the correct modes and setup the control registers. Fix it!
This fixes a regression from 7b334fcb45.
Reported-and-tested-by: Mathew McKernan <matmckernan@rauland.com.au>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977
Signed-off-by: Mathew McKernan <matmckernan@rauland.com.au>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
* 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next:
drm/nvc0: improve vm flush function
drm/nv50-nvc0: remove some code that doesn't belong here
drm/nv50: use "nv86" tlb flush method on everything except 0x50/0xac
drm/nouveau: quirk for XFX GT-240X-YA
drm/nv50-nvc0: work around an evo channel hang that some people see
drm/nouveau: implement init table opcode 0x5c
drm/nouveau: fix oops on unload with disabled LVDS panel
nv30: Fix parsing of perf table
drm/nouveau: correct memtiming table parsing for nv4x
There's no need to pass kref_put() the address of a function (just the
function will do just fine) nor to cast its unused return to void.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Switch some errors to debug output. These are generally harmless
and tend to confuse users.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is necessary even with PCI(e) GART, and it makes writeback work even with
AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth
and other AGP bridges though.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Reviewed-by: Alex Deucher <alex.deucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This has always used a big hammer, but that hammer is probably
too big, I'm also not sure its necessary but at least this
should be safe.
Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=23592
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a revert of 428d2e828c.
This is broken in the same manner as for VGA: trying to write to an
invalid address on the (currently 7-bit) i2c bus.
One notable failure appears to be for MacBooks. The scary part was that
it gave the appearance of working (i.e. reporting the absence of the
panel) on various all-in-one machines with ghost LVDS panels and not
failing for laptops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a moral revert of 6ec3d0c0e9.
Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that the code
is broken. Shock.
There are a number of issues, but following a key insight from Dave
Airlie, that 0xA0 is an invalid address on a 7-bit bus (though not if we
were to enable 10-bit addressing), and would look like the EDID port
0x50, it is possible to see where the confusion starts.
In short, a write to 0xA0 is accepted by the GMBUS controller which we
interpreted as meaning the existence of a connection (a slave on the
other end of the wire ACKing the write). That was false.
During testing with a broken GMBUS implementation, which never reset an
earlier NAK, this test always reported a NAK and so we proceeded on to
the next test.
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35904
Reported-and-tested-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Keith Packard <keithp@keithp.com>
It has been reported that this greatly improves (and possibly fixes
completely) the stability of NVA3+ chipsets. In traces of my NVA8,
NVIDIA now appear to be doing this too.
The most recent traces of 0x50 and 0xac I could find don't show NVIDIA
checking PGRAPH status on these flushes, so for now, we won't either.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Perf tables v 1.2 and 1.3 (seen on Geforce FX/ 5) are not long enough
to store the voltage label/id
v2 - Remove comment from the code
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In line with envytools, verified on 4 or 5 BIOS'es.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Avoid touching the flip setup regs while
acceleration is running. Set them at modeset
rather than during pageflip. Touching these
regs while acceleration is active caused hangs
on pre-avivo chips. These chips do not seem
to be affected, but better safe than sorry,
plus it avoids repeatedly reprogramming the
regs every flip.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
