Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-core-next

* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau: error paths leak in nvc0_graph_construct_context()
  drm/nouveau: Calculate reserved VRAM for PRAMIN value before use.
  drm/nouveau: fix nouveau_vma object leak
  drm/nouveau: fix nouveau_mem object leak
  drm/nouveau: fix fetching vbios from above 4GiB vram addresses

Two of these error paths returned without freeing "ctx".
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

'drm/nouveau: rework vram init/fini ordering a little' changed
the order of instmem.init() and nouveau_mem_vram_init() which
resulted in using ramin_rsvd_vram before it was calculated and
failing to init any accel on pre-NV50 cards.

Since it's only used on <NV50 just calculate it where it's needed
and leave it as default 0 for NV50.
Signed-off-by: NYounes Manton <younes.m@gmail.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>

It's a regression from "drm/nouveau: create temp vmas for both src and
dst of bo moves".
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>

Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-core-next

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (58 commits)
  drm/nouveau: fix off-by-one
  drm/nouveau/temp: Add default calibration values for nv67
  drm/nouveau/temp: Fix signed/unsigned int logic
  drm/nvc0: push prunk140 irq messages to debug loglevel
  drm/nouveau: un-blacklist nvce accel
  drm/nouveau: fix null pointer deref on pre-nv50 chipsets
  drm/nouveau: rework vram init/fini ordering a little
  drm/nouveau: shut lockdep up if last vm ref needs to destroy pgd
  drm/nouveau: fix display takedown order to match reverse init order
  drm/nvc0: enable per-client address spaces
  drm/nouveau: add some debug output if nouveau_mm busy at destroy time
  drm/nv50: enable use of per-client gpu address space
  drm/nouveau: remove implicit mapping of every bo into chan_vm
  drm/nouveau: remove 'chan' argument from nouveau_bo_new
  drm/nouveau: fixup gem_info ioctl to return client-specific bo virtual
  drm/nvc0: explicitly map PDISP semaphore buffer into each channel's vm
  drm/nv50-nvc0: lookup pushbuf virtual address on dma_push
  drm/nv84-nvc0: explicitly map semaphore buffer into channel vm
  drm/nv50-nvc0: explicitly map pushbuf bo into channel vm
  drm/nv50-nvc0: explicitly map notifier bo into channel vm
  ...

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

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Many (all?) of the coefficients related to calculating the
correct temperature are signed integers

This patch correcly parses and stores those values
It also ensures that the default offset is 0 (previously 1)

Affected cards - the original nv50 and the nv40 family
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We know they happen, we don't know why.  They're annoying, so hide them
from users for the moment.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported working on IRC.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Commit "drm/nouveau: add some debug output if nouveau_mm busy at destroy time"
revealed an issue where vram mm takedown would actually fail due to there
still being nodes present, causing nouveau to leak a small amount of memory
on module unload.

This splits TTM/nouveau_mm a bit more cleanly and ensures nouveau_mm fini
isn't done until all gpuobjs are also destroyed.
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: 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: 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: 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>

GPU virtual addresses are constant now so this should never be getting hit
anyway and userspace shouldn't break from them being ignored.

This is being done in preference to teaching the code how to deal with BOs
that exist at different virtual addresses within separate VMs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Greatly simplifies a number of things, particularly once per-client GPU
address spaces are involved.

May add this back later once I know what things'll look like.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Was previously assuming a page size of 4KiB unless a VMA was present to
override it.  Eventually, a buffer won't necessarily have a VMA at all at
some stages of its life, so we need to store this info elsewhere.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Abuses existing gpuobj_new() chan argument for this, which in turn forces
all NVOBJ_FLAG_VM allocations to be done from the global heap, not
suballocated from the channel's private heap.  Not a problem though in
practise.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

gpuobj really needs splitting into channel/gpuobj code instead...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Userspace hasn't passed us a channel_hint for a long long time now, and
there isn't actually a need to do so anymore anyway.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>