The execbuf utils may call reference on NULL fence objects.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add / fix some function comments.
Don't move out an fbdev framebuffer when unused. Just unpin.
Only have a single function that computes a SVGAGuestPtr from the buffer's
current placement, and make it more versatile by accepting a
struct ttm_buffer_object
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When we hae screen objects we are allowed to place the overlay source
in the GMR area, do this as this will save precious VRAM.
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since 3D requires HWv8 and screen objects is always available on those
hosts we only need the screen objects path for surfaces.
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On lower versions, the way we mix 2D and 3D may be too slow.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

More preparation for Screen Object support.
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In preperation for screen objects, still leaves the delayed workqueue
for surface updates in place.
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This will make it easier to execute commands operating on user-space
resources but generated by the kernel.

JB: Added tracking if the sw_context was called from the kernel or userspace.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Used by the vmwgfx driver.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* 'drm-intel-next' of git://people.freedesktop.org/~keithp/linux:
  Drivers: i915: Fix all space related issues.

* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6: (353 commits)
  drm/nouveau: remove allocations from gart populate() hook
  drm/nvc0/fb: slightly improve PMFB intr handling, move out of nvc0_graph.c
  drm/nvc0/fifo: avoid touching missing subfifos
  drm/nvd9/disp: bail out of mode_set_base if no fb bound to crtc
  drm/nvd9/disp: stub some more api hooks so we don't oops on resume
  drm/nouveau: fix printk typo in ioremap failure path
  drm/nvc0/pm: minor clock readback fixes
  drm/nv40/pm: execute memory reset script from vbios
  drm/nv50/gr: refactor initialisation
  drm/nouveau: if requested, try harder at disabling sysmem pushbufs
  drm/nv50/gr: enable ctxprog xfer only when we need it to save power
  drm/nouveau/dp: add support for displayport table 0x30
  drm/nouveau/dp: return master dp table pointer too when looking up encoder
  drm/nouveau/bios: simplify U/d table hash matching func to just match
  drm/nouveau/dp: preserve non-pattern bits in DP_TRAINING_PATTERN_SET
  drm/nvc0/gr: remove MODULE_FIRMWARE() lines
  drm/nouveau/dp: use alternate lane mask for nvaf
  drm/nouveau/dp: link rate scripts are selected with a comparison table
  drm/nv40/pm: write nv40-specific reclocking routines
  drm/nv40/pm: parse geometric delta clock from vbios
  ...

Since some somewhat questionable changes a while back, TTM provides a
completely empty array of struct dma_address that stays around for the
entire lifetime of the TTM object.

Lets use this array, *always*, rather than wasting yet more memory on
another array who's purpose is identical, as well as yet another bool array
of the same size saying *which* of the previous two arrays to use...

This change will also solve the high order allocation failures seen by
some people while using nouveau.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I'm still not certain how to determine the number of SUBPs are present on
a given board.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On >=nv50, userspace would still end up allocating pushbufs in GART.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch adds instructions to ctxprog and by doing, impacts context
switching performance.  My testcase showed a 1% performance cost using
glxgears that is a context-switch bound application.

Please test and report bugs/performance/power/other.

Many thanks to Maxim Levitsky for his dedicated work on lowering power
consumption with nouveau.

More patches are coming thanks to his work:

https://bugs.freedesktop.org/show_bug.cgi?id=37922Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Written from observations of my NVD9's vbios, completely untested due to
my NVD9 lacking actual DisplayPort connectors..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Will need to be able to distinguish 2.0/2.1 from 3.0 soon.  Also, move
the vbios parsing to nouveau_dp where it belongs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The caller is now responsible for parsing its own lists (or whatever) of
possible encoders.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We don't use these by default anymore, and there's been complaints from a
number of places thinking that the firmware blobs are required still.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Naturally...  Because Macs can't just be the same as everything else
now can they?
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not hardcoded as originally thought.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not 100% perfect yet, but a good start towards what it'll look like in the
end.

Actually seems stable on a NV44 I have here, as much as running around OA
for a fair amount of time constantly switching between performance levels
can prove..

My NV49 isn't quite so happy, and semaphores mess up somehow (sometimes) as
a result of the memory reclocking.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>