Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Based on an original patch by Zhenyu Wang, this initializes the BLT ring for
SandyBridge and enables support for user execbuffers.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Release the lru spinlock early.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The enter argument as implemented by commit 413d45d3 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.

There is no runtime behavior change as a result of this patch.
Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need the unlocked variant for the new codepath introduced to fix the
race condition in master recently.
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to use some of these values in eDP configurations, so be sure to
fetch them and store them in the i915 private structure.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Some devices such as the radeon chips receive information from user
space which needs to be saved when executing an atomic mode set
operation, else the user space would have to be queried again for the
information.

This patch extends the mode_set_base_atomic() call to pass an argument
to indicate if this is an entry or an exit from an atomic kernel mode
set change.  Individual drm drivers can properly save and restore
state accordingly.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This can be used by the X server to restrict mode resolutions and size of
root pixmap.

Bump minor to announce this availability.
Bump driver date.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is needed for the callback to identify the caller and take
appropriate locks if needed.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a race pointed out by Dave Airlie where we don't take a buffer
object about to be destroyed off the LRU lists properly. It also fixes a rare
case where a buffer object could be destroyed in the middle of an
accelerated eviction.

The patch also adds a utility function that can be used to prematurely
release GPU memory space usage of an object waiting to be destroyed.
For example during eviction or swapout.

The above mentioned commit didn't queue the buffer on the delayed destroy
list under some rare circumstances. It also didn't completely honor the
remove_all parameter.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=615505
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591061Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Nouveau will need this on GeForce 8 and up to account for the GPU
reordering physical VRAM for some memory types.
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Acked-by: NThomas Hellström <thellstrom@vmware.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Existing core code/drivers call drm_mm_put_block on ttm_mem_reg.mm_node
directly.  Future patches will modify TTM behaviour in such a way that
ttm_mem_reg.mm_node doesn't necessarily belong to drm_mm.
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Acked-by: NThomas Hellström <thellstrom@vmware.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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>

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>

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>

Hook the GEM vm open/close ops into the generic drm vm open/close so
that the private vma entries are created and destroy appropriately.
Fixes the leak of the drm_vma_entries during the lifetime of the filp.
Reported-by: NMatt Mackall <mpm@selenic.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

fixes https://bugzilla.kernel.org/show_bug.cgi?id=19012

cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Consolidate everything in intel-gtt.c and also kill the export
of intel_max_stolen.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

v2: Julien Cristau pointed out that @nondestructive results in
double-negatives and confusion when trying to interpret the parameter,
so use @force instead. Much easier to type as well. ;-)

And fix the miscompilation of vmgfx reported by Sedat Dilek.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Destructive load-detection is very expensive and due to failings
elsewhere can trigger system wide stalls of up to 600ms. A simple
first step to correcting this is not to invoke such an expensive
and destructive load-detection operation automatically.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29536
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16265Reported-by: NBruno Prémont <bonbons@linux-vserver.org>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the detection from intel-gtt.ko instead. Hooray!

Also move the stolen mem allocator to the other gtt stuff in dev_prv->mem.

v2: Chris Wilson noted that my error handling was crap. Fix it. He also
said that this fixes a problem on his i845. Indeed, i915_probe_agp
misses a special case for i830/i845 stolen mem detection.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25476
Cc: stable@kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Add a few definitions to it that are already shared and that will
be shared in the future (like the number of stolen entries).
No functional changes in here.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Every driver used the default implementation. Fold that one into
the only callsite and drop the callback.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Totally unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There's no point in jumping through two indirections. So kill one
and call the kernels agp functions directly.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The information supplied by userspace through these ioctls is only
accessible by dev->drw_idr. But there's no in-tree user of that.
Also userspace does not really care about return values of these ioctls,
either. Only hw/xfree86/dri/dri.c from the xserver actually checks the
return from adddraw and keeps on trying to create a kernel drawable
every time somebody creates a dri drawable. But since that's now a noop,
who cares.

Therefore it's safe to replace these three ioctls with noops and rip
out the implementation.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NKristian Høgsberg <krh@bitplanet.net>
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only used by ioctl, not by any in-tree drivers.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All drivers happily copy&pasted the default implementation without
checking whether this callback is used at all. It's not. Sigh.

Kill it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

No caller (rightly) cares about it, so drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any in-tree user. So drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It's not used by any driver. The destructor callback is unfortunately
used by the via driver in a rather convoluted piece of code used
to reimplement something resembling broken futexes. I didn't dare
to touch this code. But at least kill the needless NULL assignemt
in the sis driver.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any current driver.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any driver. So drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any driver (rightly so!). Kill them.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not used by any in-kernel driver. So drop it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

With the current screwed but its ABI, ioctls for the drm, Linus pointed out that we could allow userspace to specify the allocation size, but we pass it to the driver which then uses it blindly to store a struct. Now if userspace specifies the allocation size as smaller than the driver needs, the driver can possibly overwrite memory.

This patch restructures the driver ioctls so we store the structure size we are expecting, and make sure we allocate at least that size. The copy from/to userspace are still restricted to the size the user specifies, this allows ioctl structs to grow on both sides of the equation.

Up until now we didn't really use the DRM_IOCTL defines in the kernel, so this cleans them up and adds them for nouveau.

v2:
fix nouveau pushbuf arg (thanks to Ben for pointing it out)
Reported-by: NLinus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

unifdef-y and header-y has same semantic.
So there is no need to have both.

Drop the unifdef-y variant and sort all lines again
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Expand the crtc_gamma_set function to accept a starting offset. The
reason for this is to eventually use this function for setcolreg from
drm_fb_helper.c. The fbdev colormap function can start at any offset in
the color map.
Signed-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>