radeon_pm_in_vbl() didn't report in vblank status accurately. Make
it a wrapper around radeon_get_crtc_scanoutpos() which corrects for
biases, so it reports accurately.

radeon_pm_in_vbl() will only report in_vbl if all active crtc's
are currently inside vblank.

agd5f: use rdev->num_crtc rather than hardcoding the crtc count
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon_get_crtc_scanoutpos() returns the current horizontal
and vertical scanout position of a crtc. It also reports if
the display scanout is currently inside the vblank area.

hpos reports current horizontal pixel scanout position.
vpos reports the current scanned out line as a value >= 0
in active scanout. If the scanout is inside vblank area, it
reports a negative value, the number of scanlines until
end of vblank aka start of active scanout, e.g., -3 ==
"At most 3 scanlines until end of vblank".

This code is derived from radeon_pm_in_vbl(), tested on
R500 and R600.
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch reworks spread spectrum handling to enable it
properly on lvds and DP/eDP links.  It also fixes several
bugs in the old spread spectrum code.

- Use the ss recommended reference divider if available
when calculating the pll
- Use the proper ss command tables on pre-DCE3 asics
- Avoid reading past the end of the ss info tables
- Enable ss on evergreen asics (lvds, dp, tmds)
- Enable ss on DP/eDP links
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The recent changes to the old algo (prefer high post div)
coupled with the range and precision limitations of using
fixed point with the new algo make the new algo less
useful.  So drop the new algo.  This should work as well
or better than the old new/old combinations and simplifies
the code a lot.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30218
among others.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

These shouldn't be needed with the post div changes
in the last patch.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

the hw prefers higher post dividers
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This allows for a more exact fitting on the physical
display. The new properties default to zero which corresponds to the
previous underscan border width[height] formula:
(display_width[display_width] >> 5) + 16.

Example to set a horizontal border width of 30 and a vertikal border
height of 22:

   xrandr --output HDMI-0 --set underscan on --set "underscan hborder" 30 --set "underscan vborder" 22
Signed-off-by: NMarius Gröger <marius.groeger@googlemail.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On r6xx+ a newer fence mechanism was implemented to replace
the old wait_until plus scratch regs setup.  A single EOP event
will flush the destination caches, write a fence value, and generate
an interrupt.  This is the recommended fence mechanism on r6xx+ asics.

This requires my previous writeback patch.

v2: fix typo that enabled event fence checking on all asics
rather than just r6xx+.

v3: properly enable EOP interrupts
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=29972Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When writeback is enabled, the GPU shadows writes to certain
registers into a buffer in memory.  The driver can then read
the values from the shadow rather than reading back from the
register across the bus.  Writeback can be disabled by setting
the no_wb module param to 1.

On r6xx/r7xx/evergreen, the following registers are shadowed:
- CP scratch registers
- CP read pointer
- IH write pointer
On r1xx-rr5xx, the following registers are shadowed:
- CP scratch registers
- CP read pointer

v2:
- Combine wb patches for r6xx-evergreen and r1xx-r5xx
- Writeback is disabled on AGP boards since it tends to be
unreliable on AGP using the gart.
- Check radeon_wb_init return values properly.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Move common code to init function.

v2: make sure the bo is pinned after init as well.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

necessary for some of the vmware fixes to be pushed in.

Conflicts:
	drivers/gpu/drm/drm_gem.c
	drivers/gpu/drm/i915/intel_fb.c
	include/drm/drmP.h

* 'intel/drm-intel-next' of ../drm-next: (266 commits)
  drm/i915: Avoid circular locking from intel_fbdev_fini()
  drm/i915: mark display port DPMS state as 'ON' when enabling output
  drm/i915: Skip pread/pwrite if size to copy is 0.
  drm/i915: avoid struct mutex output_poll mutex lock loop on unload
  drm/i915: Rephrase pwrite bounds checking to avoid any potential overflow
  drm/i915: Sanity check pread/pwrite
  drm/i915: Use pipe state to tell when pipe is off
  drm/i915: vblank status not valid while training display port
  drivers/gpu/drm/i915/i915_gem.c: Add missing error handling code
  drm/i915: Don't mask the return code whilst relocating.
  drm/i915: If the GPU hangs twice within 5 seconds, declare it wedged.
  drm/i915: Only print 'generating error event' if we actually are
  drm/i915: Try to reset gen2 devices.
  drm/i915: Clear fence registers on GPU reset
  drm/i915: Force the domain to CPU on unbinding whilst wedged.
  drm: Move the GTT accounting to i915
  drm/i915: Fix refleak during eviction.
  i915: Added function to initialize VBT settings
  drm/i915: Remove redundant deletion of obj->gpu_write_list
  drm/i915: Make get/put pages static
  ...

lockdep spots that the fb_info->lock takes the dev->struct_mutex during
init (due to the device probing) and so we can not hold
dev->struct_mutex when unregistering the framebuffer. Simply reverse the
order of initialisation during cleanup and so do the intel_fbdev_fini()
before the intel_modeset_cleanup.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The display port DPMS state is tracked internally in the display port
driver so that when a hotplug event comes along, the driver can know
whether to try retraining the link. This doesn't work well if the
driver never sets the DPMS state to ON when the output is enabled.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Cancel the output polling work proc before acquiring the struct mutex
to avoid acquiring the work proc mutex with the struct mutex
held. This avoids inverting the lock order seen when the work proc
runs.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and do the same for pread.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Move the access control up from the fast paths, which are no longer
universally taken first, up into the caller. This then duplicates some
sanity checking along the slow paths, but is much simpler.
Tracked as CVE-2010-2962.
Reported-by: NKees Cook <kees@ubuntu.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Conflicts:
	drivers/gpu/drm/i915/i915_gem_evict.c
	drivers/gpu/drm/i915/intel_display.c
	drivers/gpu/drm/i915/intel_dp.c

Instead of waiting for the display line value to settle, we can simply
wait for the pipe configuration register 'state' bit to turn off.

Contrarywise, disabling the plane will not cause the display line
value to stop changing, so instead we wait for the vblank interrupt
bit to get set. And, we only do this when we're not about to wait for
the pipe to turn off.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

While the display port is in training mode, vblank interrupts don't
occur. Because we have to wait for the display port output to turn on
before starting the training sequence, enable the output in 'normal'
mode so that we can tell when a vblank has occurred, then start the
training sequence.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Extend the error handling code with operations found in other nearby error
handling code

A simplified version of the sematic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r exists@
@r@
statement S1,S2,S3;
constant C1,C2,C3;
@@

*if (...)
 {... S1 return -C1;}
...
*if (...)
 {... when != S1
    return -C2;}
...
*if (...)
 {... S1 return -C3;}
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

The return from move_to_gtt_domain() may indicate a pending signal which
needs to handled as opposed to an actual error, for instance, so report
the original return value rather than forcing an EINVAL.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The issue is that we may become stuck executing a long running shader
and continually attempt to reset the GPU. (Or maybe we tickle some bug
and need to break the vicious cycle.) So if we are detect a second hang
within 5 seconds, give up trying to programme the GPU and report it
wedged.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

So far only found registers for i830, i845, i865 and one of those has no
effect on i865!

At this moment in time, attempting to reset i8xx is a little
optimistic...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When the GPU is reset, the fence registers are invalidated, so release
the objects and clear them out.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30083Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Only drm/i915 does the bookkeeping that makes the information useful,
and the information maintained is driver specific, so move it out of the
core and into its single user.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>

If the soon-to-be scanout buffer is partly covering the intended
VRAM region, move and pin will fail. In that case, just move it out
to system before attempting to move it in again.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The removed code causes oopses with newer drms on master drop.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is to avoid accessing uninitialized data during
drm_irq_uninstall and vblank ioctls. At the same time, enable error check from
drm_kms_init which previously appeared to ignore all errors.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We add an option not to enable fbdev, this option is off (0) by default.
Not enabling fbdev at load time makes it possible to co-operate with
vga16fb and vga text mode when VT switching.

However, if 3D resources are active when VT switching, we're currently
not able to switch over to vga, due to device limitations.
This fixes a bug where we previously lost 3D state during VT switch.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm/vmwgfx: Fix breakage introduced by commit "drm: block userspace under allocating buffer and having drivers overwrite it (v2)"

The mentioned commit breaks the vmwgfx ioctl argument sanity check.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In order to be fully threadsafe we need to check that the drm_gem_object
refcount is still 0 after acquiring the mutex in order to call the free
function. Otherwise, we may encounter scenarios like:

Thread A:                                        Thread B:
drm_gem_close
unreference_unlocked
kref_put                                         mutex_lock
...                                              i915_gem_evict
...                                              kref_get -> BUG
...                                              i915_gem_unbind
...                                              kref_put
...                                              i915_gem_object_free
...                                              mutex_unlock
mutex_lock
i915_gem_object_free -> BUG
i915_gem_object_unbind
kfree
mutex_unlock

Note that no driver is currently using the free_unlocked vfunc and it is
scheduled for removal, hasten that process.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30454Reported-and-Tested-by: NMagnus Kessler <Magnus.Kessler@gmx.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that we hold onto a reference whilst evicting objects, we need to
be sure that we drop all the references taken -- even on the error
paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

There were lots of places being inconsistent since handle count
looked like a kref but it really wasn't.

Fix this my just making handle count an atomic on the object,
and have it increase the normal object kref.

Now i915/radeon/nouveau drivers can drop the normal reference on
userspace object creation, and have the handle hold it.

This patch fixes a memory leak or corruption on unload, because
the driver had no way of knowing if a handle had been actually
added for this object, and the fbcon object needed to know this
to clean itself up properly.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Added a function that sets the LVDS values to default settings.  This
will be called by intel_init_bios before checking for the VBT (video BIOS
table). The default values are thus loaded regardless of whether a VBT
is found.

The default settings in each parse function have been moved to the new
function. This consolidates all the default settings into one place.

The default dither bit value has been changed from 0 to 1.  We can
assume that display devices will want dithering enabled.
Signed-off-by: NSimon Que <sque@chromium.org>
Acked-by: NOlof Johansson <olof@lixom.net>
[ickle: fixup for -next]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>